2.1    AUTOMATED COMMUNUNICATIONS SYSTEMS - GENERAL
Using the Defense Information Infrastructure (DII) as a backbone, the Navy has designed automated systems ashore and afloat to process message traffic with minimal intervention by communications personnel. Figure 2-1 depicts the system flow. This chapter describes these systems, providing information to the communicator to assist in effective management of these systems.
The Navy's automated software based communications systems are dynamic. To keep these systems current users can propose improvements or report defects in the software systems used by the Navy.
2.2              MESSAGING SYSTEMS
One of the most important concepts of operating in an organization that is spread across the globe is not just the ability to communicate, but to communicate quickly, effectively, securely, and with full accountability. With the development, fielding, and proliferation of Internet Protocol (IP) based communications (i.e. E-mail and Internet Relay Chat), the desire is to quickly share information by any means available and people do.
With that in mind, the average user would think that with all of the e-mail and chat going on in the Navy that record message traffic would soon be replaced. To the contrary, Navy personnel have not only continued to use record message traffic, but have exceeded the capabilities of messaging systems and their associated communications paths.
With constantly stressed low data rate (LDR) communications networks such as the Common User Digital Information exchange Subsystem (CUDIXS), the need to maximize use of the “new” IP paths has become a driving force in the future of Naval Messaging. Even with existing systems (i.e. pre-DMS) we find the need to adapt to our available resources.
2.2.1          DMS OVERVIEW
The DMS employs the messaging and directory services using internationally recognized cOTS-based X.400 and X.500 messaging and directory products. The DMS COTS baseline, which includes DoD military messaging, directory, and security enhancements, provides the messaging infrastructure for DoD electronic organizational messaging support. The DMS messaging and directory components are managed and protected by specialized systems management and security support mechanisms and components. The DMS management system uses system management tools and message tracing applications to isolate and identify problems and to report on the health and welfare of the DMS infrastructure.
Protocols and components of the Multi-level Information Security Service Initiative (MISSI) provide DMS security services. The MISSI Message Security Protocol (MSP) and the Fortezza encryption card provide encryption and digital signature services. Each Fortezza card contains encryption keys that are based on the organization or command's authorized level of clearance and digital certificates that are unique to the card's assigned organization. A designated Certification Authority (CA) uses a CA Workstation (CAW) to generate and post the encryption keys and digital certificates to the organization's Fortezza card and to the DMS X.500 directory. The MSP and the Fortezza card generate and exchange security tokens that support the exchange of digitally signed and encrypted messages between DMS users.
DMS network transport services are provided by the Defense Information Systems Network (DISN) and secure dial-up connections. DoN users receive DMS services or enabling capabilities through the allocation of various levels of messaging, directory and network management services, and DISN network or dial-up connectivity.
2.2.1.1           TACTICAL MESSAGE GATEWAY (TMG)
The MFI is an infrastructure-level component that provides protocol conversion between the DMS MTS and the DTH legacy- messaging environment. The MFI is the primary means of providing interoperability with DTH users that have not migrated to DMS, including the Allied and tactical users. MFI'S are typically located in DISA managed DMS Transition Hubs (DTH), which include legacy switching centers, or Navy LNOSC locations. The DMS automatically routes messages through an MFI whenever the recipient's DMS X.500 directory address contains a legacy preferred delivery attribute.
2.2.1.2       CERTIFICATION AUTHORITY WORKSTATION (CAW)
The CAW is a National Security Agency (NSA) certified and approved workstation that provides enabling technology that supports messaging security services of confidentiality, integrity, authentication, and non-repudiation. Organizations use the CAW for programming identities onto Fortezza Cards, generating public-key certificates, and posting security information to the DMS X.500 directory. An appointed CA is responsible for operating the CAW, programming Fortezza cards, and using the CAW along with an ADUA to post certificates and security information to the DMS directory.
2.2.1.3       MESSAGE CONVERSION SYSTEM (MCS)
Currently, the Defense Message System-Message Conversion System (DMS-MCS) is operational at the DISA DTH located at Fort Detrick MD. As fielded, the DMS-MCS is comprised of the Message Conversion System Message Processor (MCSMP), the MCS Directory Component (MDC), the Central Directory Component (CDC), and the Update Authority Component (UAC). The UAC portion of the DMS-MCS is located at NCTAMS LANT and NCTAMSPAC. The Navy has fielded Regional MCS' at the two NCTAMS. The Regional MCS configuration consists of the MCSMP and the MDC. Changes were made to provide supportable, removable hard drive capability and to provide a Mode I interface to the NOVA System. Although the UAC and CDC are not considered part of the Regional MCS configuration, the Regional MCS receives Plain Language Address (PLA) updates from the CDC via the SIPRNET.
The primary purpose of the Regional MCS is to provide PLA-to- Routing Indicator (RI) look up and assignment. After receiving a message from the host NOVA System, the Regional MCS will validate the message, assign the appropriate RI(s) and return the message to the NOVA for delivery. If invalid PLAs are found by MCS, the MCS will automatically generate a service message to the originator. Each invalid PLA will receive a RI of RUBDPLA side routed on the original message. The MCS provides a means of inserting Routing Indicator(s) (RI'S) in an ACP128 formatted message based on the PLAs contained in that message. Currently, any U.S. General Service (GENSER) subscriber employing ACP128 format and sending narrative pattern traffic may, upon approval, use the DMS-MCS for PLA-to-RI conversion. Both the Navy Regional MCS and DMS-MCS are transitional systems to aid customers in the migration from AUTODIN to DMS. Even though these systems are transitional, both are designed to remain viable until the phase­out of the AUTODIN system is completed.
2.2.1.4   DMS AND TACTICAL DMS PROXY AFLOAT SYSTEM
The Tactical Messaging DMS proxy system at TMG sites provides the ability to interface and translate DMS messages to and from tactical units, using approved DMS infrastructure components. The NCTAMS sites have a direct interface to legacy systems and have the Tactical Messaging DMS proxy capability which is supported by the Integrated Shipboard Network System (ISNS) hardware with software provided by the Common PC Operating System Environment (COMPOSE).
2.2.1.5       DEFENSE MESSAGE DISSEMINATION SYSTEM (DMDS)
DMDS is an end user message profiling application that automatically profiles and disseminates a command or organization's incoming message traffic. The organization can configure DMDS to distribute the profiled messages in either encrypted or unencrypted form. If DMDS distributes encrypted messages, all recipients will need Fortezza security services. Organizations must protect local networks that distribute unencrypted DMS messages in accordance with guidelines set forth in OPNAVINST 523 9.1.
2.2.1.6     MAIL LIST AGENT (MLA)
The MLA provides a collective addressing capability for DMS. The MLA receives messages addressed to a collective address called a Mail List and redistributes them to those recipients who are members of the Mail List. The Mail List in DMS is similar to the Address Indicator Groups (AIG), Collective Address Designators (CAD), and task force designators (TF) used in the DTH legacy system. The MLA accepts delivery of a message addressed to a Mail List only from the user(s) authorized to submit messages to that Mail List. The MLA adds each member of the Mail List as a recipient to the message. If it is an encrypted message, the MLA generates a token for each recipient so recipients can decrypt the message.
DIRECTORY SYSTEMS AGENT (DSA)
The DSA serves as a repository for the DMS directory information. This information, known as the Directory Information Base (DIB), contains organizational user attribute information such as the organization's directory name, digital certificates, network address information, and administrative information such as telephone numbers and mailing addresses. The DIB is distributed throughout the directory system in multiple DSA'S. Users access the DSA through the IDUA, a directory browser application.
2.2.1.8       BACKBONE MESSAGE TRANSFER AGENT (BMTA)
BMTA'S function as high-level message store-and-forward switches within the DMS MTS. BMTA'S are installed at DMS infrastructure level sites (i.e., Defense Information Systems Agency (DISA) Regional Network Operations and Security Centers (RNOSC) and Regional Nodes (RN)). BMTA'S serve as independent store-and- forward message switches between LNOSC'S, USMC LCC'S, major claimant sites, and DISA operated DMS infrastructure sites.
BMTA'S are generally downward connected to one or more LMTA'S or primary GWS'S and either laterally or upwardly connected to other BMTA'S. The BMTA receives messages from other BMTA'S located throughout the global DMS infrastructure and routes them according to specific routing algorithms.
2.2.1.9       LOCAL MESSAGE TRANSFER AGENT (LMTA)
The LMTA functions as an intermediate-level message switch that stores and forwards messages across a fully interconnected switch fabric called the MTS. LMTA's typically reside at LNOSC sites and store and forward message traffic destined to and from DMS specialty products (i.e., PUA, Mail List Agent (MLA), MultiFunction Interpreter (MFI)). LMTA'S are bound to a local DMS Directory System Agent (DSA) and make routing decisions based on specific information stored in the X.500 directory.
2.2.1.10       HIGH ASSURANCE GUARD (HAG)
The DMS HAG is a secure "gateway" component installed in the DMS secret messaging domain that selectively allows or denies message exchange between DMS NIPRNET and SIPRNET messaging domains. The HAG examines each message to ensure that：
1.  The organization has digitally signed and encrypted messages exchanged between NIPRNET and SIPRNET domains.
2.  Message originators and recipients are authorized to exchange messages between the DMS NIPRNET and SIPRNET messaging domains.
3.  All exchanged messages via the HAG are appropriately marked as unclassified.
4.  Messages exchanged between the two messaging domains may include file attachment(s) if the rules listed below are followed：
a.  Attachment types must be limited to specific file extension types authorized by the organization as being crucial to mission accomplishment.
b.  All messages must be signed and encrypted with hard- token Class IV Fortezza to provide authentication and non-repudiation.
c.  The DMS HAG must be capable of decrypting messages to ensure attachments are of the appropriate types and to perform a dirty word search.
d.  The organization must define the HAG Access Control List (ACL) to limit the users who can send attachments from low to high.
The HAG also passes directory information between specific directory servers in the two messaging domains. Unclassified directory information for message recipients in both messaging domains is accessible to users on the NIPRNET. Changes and updates to the unclassified directory information are passed through the HAG to the SIPRNET domain through a process known as directory shadowing.
2.2.1.11         SERVICE MANAGEMENT SYSTEM (SMS)
The SMS supports monitoring and control of DMS components at various management levels. The SMS is comprised of a data base system as well as specialized message trace applications, directory administration tools, and fault management applications for collecting data and reporting on the status of DMS components. The SMS message trace and fault management applications run on a DMS component called the Management Workstation (MWS). Directory administration is performed using a DMS component called the Administrative Directory User Agent (ADUA). The MWS also incorporates a trouble ticket system for tracking and managing system problems and outages. The SMS applications and its MWS and ADUA hardware component systems are typically installed at Navy LNOSC locations and USMC Control Centers.
2.2.1.12       GROUPWARE SERVER (GWS)
The GWS is a component that stores and forwards messages from the DMS client to Primary Groupware Servers (PGWS) or Local Message Transfer Agents (LMTA). The GWS, PGWS, and LMTA all serve as store-and-forward message switching devices within the DMS architecture. The GWS operates at the lowest level in the DMS Message Transfer System (MTS). The GWS provides direct message store-and-forward support to DMS clients. The PGWS and LMTA provide second echelon message store-and-forward support to local or remote GWS'S. The GWS, PGWS, and LMTA components are frequently co-located at sites with large concentrations of DMS clients. Typically, these components will be centrally located at Navy LNOSC'S. The USMC typically will deploy GWS'S down to the major command level. DmS clients must use dial-up connections whenever DISN network connectivity is not available and the GWS is remotely located.
Message Store (MS)
The MS serves as an intermediary between the DMS client and a GWS. The MS resides on the GWS and serves as an electronic mailbox for the DMS client. The MS or GWS mailbox accepts and stores messages on behalf of the organization until recipients download and delete the messages.
DMS Client or User Agent
The client, sometimes referred to as the User Agent (UA), is a software application installed on a DMS-compliant hardware platform. The DMS client enables the preparation, review, release, submission, delivery, storage, archiving, display, and printing of DMS messages. A single hardware platform and a single DMS client application may support multiple users. The DMS client also contains an Integrated Directory User Agent (IDUA). The IDUA function allows the user to search the directory for addressing information that can be added directly to drafted messages or cached in the user's Personal Address Book (PAB) for later use.
2.2.2           TROUBLE MANAGEMENT SYSTEM (TMS)
To support the goal of increased reliability, Enterprise Network Management System (ENMS) has been fielded with a Trouble Management System (TMS) as an integral part of the network management tool set. TMS is based on the commercial “Remedy” product that is used extensively in the private sector to provide relevant data on network performance. TMS will be used by the shore establishment to track, from inception to completion, all events impacting service to individual or multiple units. ENMS will build databases that identify trends and provide hard data on performance that our current infrastructure is incapable of doing. That will aid in decision making about where to expend our precious fiscal and manpower resources to improve C4 service to the warfighter.
As with any automated system, the manner in which data is entered is critical to its success. TMS has the capability to automatically extract data from COMSPOT reports and fleet service advisories when presented in specific formats. To realize the capabilities that TMA offers, message drafters must take great care to ensure that data fields relevant to the incident at hand are formatted as directed herein. Messages not properly formatted
will result in delayed action due to unnecessary human intervention.
For COMSPOT reporting format and further guidance refer to Appendix B.
2.2.3   AUTOMATED MESSAGE STORE AND FORWARD (NOVA)
NOVA is a UNIX based, base-level Mode 1 store and forward terminal (Figure 2-2) dependent on the worldwide switching functions of the DTH to relay messages to other commands outside the immediate area of responsibility, services and agencies.
NOVA is a store and forward switching system that provides automated readdressal and quote functions for authorized users. For message accountability purposes, the system assigns a unique Processing Sequence Number (PSN) to each message received. This PSN provides a means of message recall and is used as part of an automated readdressal or quote request. NOVA provides duplicate checking and First-In First-Out (FIFO) by precedence processing. Received messages are sorted by routing indicator and delivered to the DTH and backside terminals, using Mode 1 protocol. NOVA performs validation of format lines 2 through 4, 12a, 12b, 15 and 16 of ACP 128 messages. Messages found to be in error are diverted to a Service Intercept Position (SIP) for manual intervention. If the message cannot be corrected at the SIP the message will be serviced by the NOVA operator. Installation of the nOva Virtual Circuit Protocol (VCP) brings a Local/Wide Area Network interface into the NOVA application in addition to the AUTODIN Mode One interface. Use of this interface reduces the number of connections to the DTH.

 

2.2.4           PERSONAL COMPUTER MESSAGE TERMINAL (PCMT)
PCMT is a microcomputer-based message processing system designed for low-volume telecommunications facilities. This store-and- forward processing system is operated by message center or fleet center personnel. PCMT provides exchange of messages between the telecommunications facility and user organizations using diskette media, Secure Telephone Units (STU) III or dedicated connectivity.
2.2.5           GATEGUARD
GateGuard serves as the primary legacy system interface point for DoN Organizations. It provides a gateway communication link from the AUTODIN Subscriber Terminal (AST) (e.g., Nova, MDT or PCMT) to an organization's Automated Information System (AIS) or Office Automation System (OAS). GateGuard was the first DoN messaging system to fulfill the "idea" of extending messaging services to the user level. Traffic received by the Nova, MDT or PCMT can be transferred electronically to GateGuard, which will ensure only

traffic of a classification level not exceeding that of the OAS communications line is transferred. GateGuard is capable of processing Unclassified to Top Secret SPECAT A type messages.
GateGuard can function as either a dedicated delivery device (paper or diskette) or as a gateway. The GateGuard system is composed of three elements： A Guard Device (for use on dedicated links), an AUTODIN Gateway Terminal (AGT), and a Gateway Communication Link to an arbitrary AIS. The AST communication link uses Local Digital Message Exchange-Remote Information Exchange Terminal (LDMX-RIXT) communication protocol. To the AST, GateGuard appears to be an attached RIXT and is also capable of providing a Mode I interface to suitably equipped hosts. The AGT is designed for operation by an organization's administrative personnel. The AGT can provide paper or diskette media for message dissemination within the organization. GateGuard exchanges data with the supporting AST using the communications link or diskette media. Unless a DMS-approved automated message release capability is available on the AIS, messages cross the communication link from the GateGuard to the AIS in one direction. The GateGuard performs the following functions：
1.  Audit Trail.
2.  User Identification.
3.  Message Storage and Retrieval.
4.   Format Checking.
5.  Security Checking.
6.  Precedence Notification.
7.  Message Routing.
8.  AST Mode I Interface.
If the communications link between GateGuard and the AST is not contained entirely within controlled spaces, it must be covered by approved communication security (COMSEC) equipment. The circuit must be covered even if only UNCLASSIFIED messages are exchanged. A KG-84 may be used to cover a circuit that will carry messages of any classification. STU III may be used to cover circuits that pass messages classified up to and including TOP SECRET.
2.2.6   FLEET MESSAGE EXCHANGE (FMX)
Fleet Message Exchange (FMX) replaced the Naval Computer Processing and Automatic Routing System (NAVCOMPARS). Whereas NAVCOMPARS consisted of five, loosely joined sites using similar
applications, FMX implemented a tightly integrated system of two sites running identical, interacting applications and using a worldwide tactical network to share data and resources. The FMX application rides on a layer of trusted, advanced commercial off- the-shelf (COTS) software: two UNIX operating systems, a Relational Database Management System (RDBMS), TCP/IP based LAN software, and an X Windows Graphical User Interface (GUI). The application operates on a platform of advanced computers connected locally by an Ethernet LAN and worldwide by the Defense Information Systems Network (DISN). Figure 2-3 depicts the in­line system configuration.
Two operating sites have been established for FMX; one at NCTAMS PAC Honolulu, HI and NCTAMS LANT Norfolk, VA. FMX consists of three separate components. One of these is a new system that is responsible for keying the fleet broadcast (BCST) and providing the necessary functionality to support the fleet broadcast requirements. This component is the Fleet Broadcast Keying System (FBKS). To reduce development time and need for operator interaction, FBKS was developed as a simple store and forward system. It runs on the same hardware platform as DUSC. Although FBKS and DUSC are functionally separate systems, they share the same database and use the same message parsing and validation software.
FBKS is connected on the backside of the NOVA system. In addition to providing the interface to FBKS, NOVA system provides the interface to the existing Common User Digital Information Exchange System (CUDIXS) and provides routing and alternate routing between circuits for FBKS and CUDIXS.
DIRECTORY UPDATE SERVICE CENTER (DUSC)
The Directory Update and Service Center (DUSC) is a multi-purpose system that will produce directory updates for the Defense Message System (DMS) Update Authority Component (UAC) and database updates for the FMX. The updates will be automatically produced from communications guard shift messages and collective update messages. DUSC will also process communications guard list request messages and allow operators to service fleet messages with errors found by the DMS Message Conversion System (MCS). DUSC performs the following functions：
1.  Provides for operation of the service message center.
2.  Produces directory updates for the DMS UAC from Communications Guard Shift (COMMSHIFT) messages and Collective update messages.
3.  Produces database update messages for FMS and FMX systems.
4.  Processes Communications Guard List (COMMGRDLST) request messages.

5.  Provides access to the CDC for query purposes.
6.  Two operating sites have been established, one at NCTAMS PAC, Honolulu, HI, and the other at NCTAMS LANT, Norfolk,
VA. NCTAMS PAC will be designated as the Master DUSC (MDUSC) and NCTAMS LANT will be the Alternate DUSC (ADUSC). The MDUSC is the only site that will be allowed to provide update transactions for the UAC. The ADUSC will have the capability of assuming full DUSC responsibilities of the MDUSC for contingency purposes.
Commshifts are processed at the DUSC system. The DUSC system sends updates to the UAC (Update Authority Component). The UAC then updates the CDC (Central Directory Component). The CDC then updates/replicates information to all MSC's (Message Conversion System). The DUSC also sends commshift updates to the FSM and FMX sites.

NEWSDEALER Message Switching System, much like the NOVA system, acts as the AUTODIN by-pass. NEWSDEALER MSS performs message switching, message safe storage, and message origination, creating a record communications infrastructure supporting the entire Intelligence Community. Both Defense Special Security Communications System (DSSCS) and General Service (GENSER) messages are exchanged. This system provides record communications for selected United States SIGINT System (USSS) field sites. Fielded systems have the capability to communicate with each other via the National Security Agency's wide area network (NSANet). Message routed outside of the USSS community are routed over the Defense Messaging Transition Hubs (DTH) or one of the NEWSDEALER Bridge Sites connecting NSANet and the Joint Worldwide Intelligence Communications System (JWICS).
Each NEWSDEALER is capable handling the ACP-128, DOI-103, DOI-103 Special format and Abbreviated Message Format (AMF). These systems may interface with computers, Automatic Message Handling System (AMHS), Message Correction System, Mode I and II circuits, STUIII Dial-up, and Virtual Circuit Protocol (VCP).
NEWSDEALER AMHS has simplified the task of drafting ACP, DOI 103, and DOI 103 Special formatted messages where as the actual message format is transparent to the user. AMHS provides simplified message drafting, coordination, and release of outgoing messages and a message internal distribution and delivery function for incoming messages.
A Virtual Circuit Protocol (VCP) has been defined to encapsulate record messages and transmit them using TCP/IP. As an added measure of security, a short header attached to the front of each VCP message transmitted contains a transaction ID indicating that it is a record message and the message size.
2.2.10   NAVAL MODULAR AUTOMATED COMMUNICATIONS SUBSYSTEM (NAVMACS)
NAVMACS is designed to increase the speed, efficiency and capacity of naval afloat and ashore communications operations.
The NAVMACS modular concept allows the system to be configured according to the particular afloat platforms' requirements.
Current versions of NAVMACS are：
1.  NAVMACS (V)2 provides up to four channels of fleet broadcast input； subscriber satellite interface to CUDIXS； and, the capability for on-line messaging. The (V)2 installation includes： computer (AN/UYK-20), teleprinter, printers, magnetic tape unit, paper tape unit and computer/satellite interface unit.
2.  NAVMACS (V)3 offers more automated features for fleet users. The V3 program provides four channels of fleet broadcast input, four channels of Full Period Termination directly on­line with the system and a subscriber satellite interface to CUDIXS. NAVMACS V3 will support 2.4kbps NON-DAMA or DAMA operations via the CUDIXS link. The (V)3 installation includes： two computers (AN/UYK-20), video display units, printers, magnetic tape units, paper tape unit and computer/satellite interface unit.
3.  NAVMACS (V)5 enhances automated communications with the addition of remote terminals for message input. The system also provides a subscriber satellite interface to CUDIXS.
To allow drafters at remote locations as well as message center personnel the opportunity to edit and retrieve messages, storage is on disk in addition to magnetic tape. The (V)5 suite includes： three computers (AN/UYK-2 0A or AN/UYK-44), video display units, RD-433 disks, magnetic tape units, paper tape units, computer/satellite interface unit and printers.
(a) This system provides the operator with 24 flexible- purpose serial input/output (i/o) channels which can be configured as any of the following：
1.      75, 300, 600, 1200 baud circuits.
2.    "Daisy-chained" remote displays and printers.
3.      Remote systems, e.g., CVIC.
4.     High speed tape readers.
5.     High speed tape punches.
6.      Compatible remote systems, e.g., Naval Intelligence Processing System (NIPS), and Personal Computer Remote System and (PCRS).
4.    NAVMACS (V)5A like NAVMACS (V)5 also enhances automated communications with the addition of remote terminals for message input. This system was developed primarily for the AEGIS equipped ships. The system also provides a subscriber satellite interface to CUDIXS. To allow drafters at remote locations as well as message center personnel the opportunity to edit and retrieve messages, storage is on disk in addition to magnetic tape. The (V)5A installation includes two AN/UYK-2 0A or AN/UYK- 44 computers； three AN/USQ-69 video display units in the main communications space and up to eight more for remote message input/output； two RD-433 disks, for program loading and short term message storage； two AN/USH-2 6 cartridge magnetic tape units (CMTUs) for backup program loading and long term message storage； two RD-3 97/UG Paper tape units for message input/output； an ON- 143(V) interconnecting box for interface between the computer and the satellite RF equipment； and three TT-624 high-speed printers located in main communications. It provides the operator with 14 flexible-purpose serial input/output (i/o) channels which can be configured as any of the following:
a.  75 baud circuits.
b.  "Daisy-chained" remote displays and printers.
c.  External systems, e.g., CVIC.
d.  High or low speed tape readers.
e.  High or low speed tape punch
f.  Compatible remote systems, e.g., Naval Intelligence Processing System (NIPS), Personal Computer Remote System (PCRS)
5.   NAVMACS II is a communications processor that provides message services to end users as well as command, control, and communications (C3) systems and will ultimately replace older versions of NAVMACS. It can be configured as either an afloat platform or as an ashore site. NAVMACS II replaces various communications systems previously employed by the U.S. Navy and all outdated versions of NAVMACS (V1 through V5/V5A). The purpose of NAVMACS II is to receive process, store, distribute, and transmit internal and external messages automatically.
NAVMACS II provides interfaces to multiple external systems of the DMS, including land lines and radio frequency (RF) circuits. It also provides interfaces to local systems within the NAVMACS II network. NAVMACS II is supported by software that performs the communications processing required by all connected systems, including a user interface. It allows end users to perform a variety of tasks, based on their security clearance level, authorization, and need. Basic tasks include reading and sending messages to other users on site. Advanced tasks include configuring system databases and performing system administration (Figure 2-4).
NAVMACS II is configurable on a site-by-site basis for the unique requirements of its users. The system (designated AN/SYQ-7A(V))
architecture is based on the Tactical Advanced Computer-3 (TAC- 3), a Hewlett-Packard™ 700 series computer. The minimum requirement for NAVMACS II is one TAC-3 computer (with the UNIX- based HP-UX™ operating system) configured as a “main communications” processor. The NAVMACS II main communications processor handles the processing and storage of all incoming and outgoing messages at a site, and is normally located in a site's primary communications area. Another type of processor may also be required in the main communications area to provide interfaces to external communication systems. This processor is the NAVMACS II Communications Controller (NCC). At sites with multiple users requiring access to NAVMACS II, additional TAC-3 computers may be configured as severs and clients on local area networks (LANs). Personal computers (PCs) may also be configured as clients.

 

Figure 2-5 CUDIXS Capabilities
2.2.12   SUBMARINE SATELLITE INFORMATION EXCHANGE SUBSYSTEM (SSIXS)
The SSIXS provides the SSN/SSBN Commanding Officer with an optional satellite path to complement existing VLF/LF/HF broadcasts. When the position of the submarine permits visibility of a satellite, and where the tactical situation permits exposure of a submarine mast-mounted antenna, the sub­system provides rapid exchange of digital information between SSN/SSBN submarines and shore stations. It also provides access to the satellite path through a programmable mixture of query-

response and broadcast without query so as to provide maximum operational flexibility to the submarine commander. All transmissions provide automatic, reliable, long range, and cryptographically secure UHF communications between submarines and shore stations and submarines themselves.
SSIXS has the same equipment configuration as CUDIXS, except SSIXS uses magnetic tape for message storage. Additionally, the shipboard version of SSIXS has an ON-143(V)6 microprocessor for interface via satellite with the shore SSIXS.
.13 BATTLE GROUP INFORMATION EXCHANGE SUBSYSTEM (BGIXS)
Battle Group Information Exchange Subsystem (BGIXS) provides the BG Commander on a properly equipped CVN or LHA/LHD dedicated battle group additional SATCOM support.
The BGIXS provides capability for direct, two-way, tactical communication between deployed battle group units and submarines at 4800 or 9600 bps.
2.2.14 NAVY REGIONAL ENTERPRISE MESSAGE SYSTEM (NREMS)
NREMS is the initiative to reduce the number of Navy DSP sites from five to two, eliminating the need for client-server DMS architecture and eliminating need for FORTEZZA cards / readers at the command desktop. NREMS provides web-based messaging capability that allows users (with accounts) to send and receive DMS messages using a web browser or via SMTP. The benefits are that it replaces current client-server DMS architecture and FORTEZZA at the command desktop and enables customers to use a personal computer web-browser to generate/receive messages and eliminate desktop software patches required by DMS.
NREMS provides DMS message service through the use of a web browser or SMTP e-mail client. Automated Message Handling System (AMHS) implements on-site redundancy and full Continuity of Operations Planning (COOP) capability between NCTAMS LANT and NCTAMS PAC. NREMS is scheduled to be complete in 2008.
FLEET BROADCASTS
GENERAL INFORMATION
With certain exceptions all ships, either individually or through guard ship arrangements will copy the Fleet Broadcast.
2.3.2           CONTROL OF THE FLEET BROADCASTS
Control of the Fleet Broadcasts is the responsibility of the FLTCOM's and/or numbered Fleet Commanders and is accomplished by four distinctive components of the Fleet Broadcast Communications System. These four components consist of：
1.  Broadcast Control Authority (BCA). The BCA implements an approved Fleet Broadcast, e.g., MULCAST, OPINTEL, RATT, for a specific communications area and provides direction and guidance to govern its assigned broadcast employment, configuration, and content. The responsibilities of a BCA may be self-assumed or delegated to a designated alternate.
2.  Broadcast Control Station (BCS). The BCS provides all the technical aspects of affecting a Fleet Broadcast, which include assembling key streams received from the various Broadcast Keying Stations (BKS) into specific broadcast channels and delivering a composite key stream to the Broadcast Radiating Station (BRS) for transmission. BCS and BRS are normally integral parts of a NCTAMS. Stations that possess a TD-1150 and have connectivity to a particular BKS and BRS have the ability to perform BCS functions.
3.  Broadcast Keying Station (BKS). The BKS introduces message or facsimile traffic into the Fleet Broadcast Network by generating a key stream of broadcast-bound information to the BCS for specific channel allocation before being forwarded to the BRS for broadcast transmission. Because of the diversity of broadcast-bound information, various BKS'S within the NAVCOMMAREA may key individual channels of multi­channel broadcast.
4.  Broadcast Radiating Station (BRS). The BRS radiates the broadcast signal to the Fleet via Satellite, Super High Frequency (SHF), and/or Low Frequency (LF). Both area NCTAMS have the ability to rekey/radiate individual broadcast channels via 75BPS Guard Numbers on all DAMA networks upon approval from the numbered fleet commander controlling the broadcast. Additionally, those units that possess SHF terminations can receive individual broadcast channel support or receive the entire aggregate from area BCS via FCC-100 connectivity.
2.3.3           COMMUNICATIONS GUARD REQUIREMENTS
Cognizant FLTCOM's require all commissioned ships and commands afloat to guard their assigned broadcast(s). Commands can meet this requirement by actively copying the broadcast or having the assigned broadcast screen ship in company supply the type channel of required broadcast. Only the vessels listed below are exempt from the above communications guard requirement：
1.  Foreign manned MSC Ships (USNS).
2.  Contract operated/tankers manned by civilians (USNS).
3.  Time chartered ships under the operational control of MSC (SS).
4.  Voyage chartered ships not under the operational control of the MSC, and cargo carrying ships at Berth (traffic rates).
With the advent of Automated Systems such as Fleet SIPRNET Messaging (FSM), SHF Gateguard units do not routinely submit COMSHIFTs when entering port. Units that do not resubmit COMMSHIFTs and lose primary delivery paths are cautioned that if primary path and secondary (ZOV path) are lost, Category I and II messages can and will be sent to tertiary paths listed in the latest COMMSHIFT on file at the Master Update Authority. For those units listing Fleet Broadcast channel (usually common channel) as an authorized ZOV route will have message traffic transmitted to it. Subsequently for those units not guarding the Fleet Broadcast while in port could possibly encounter numerous non-deliveries since the Fleet Broadcast does not require operator acknowledgement after the message is generated from the Fleet Message Exchange System (FMX). It is highly recommended that units that do not intend to monitor the Fleet Broadcast or CUDIXS termination while inport, have those ZOV routes removed from their COMSHIFT and replaced by a shore messaging system such as dial-in Gateguard or over the counter service to area NCTAMS.
2.3.4           BROADCAST IDENTIFICATION
Unique four-letter designators identify broadcasts. The first letter indicates the naval communication area (L-Atlantic and Mediterranean, P-Pacific). The second and subsequent letters identify whether it is a single or multiple channel broadcast and the broadcast type. NCTAMS LANT has assumed broadcast functions for the Atlantic and Mediterranean regions thusly removing the “M” designator that most communicators became familiar with. Additionally, NCTAMS PAC has conducted the same type merger for IMUL (Indian Ocean) Broadcast.
2.3.5     FREQUENCIES
Each NCTAMS generates Daily Communications Status Report Messages (often referred to as the 2301Z) that provide current down-link frequencies for UHF broadcast along with individual guard numbers for single channel DAMA support. In the rare event High Frequency (HF) support is required, submit Immediate precedence COMSPOT to the area NCTAMS to determine if single channel support is available in that area. HF, Multi-channel support is no longer offered to fleet units.
CIRCUIT CONFIGURATION
The source documents for block diagrams, equipment descriptions and quality control monitoring procedures for circuits are the Communications Quality Monitoring System documents (SPAWARSYSCOMINST 2 700.1 and SPAWARSYSCOMINST C2700.2) dated 27 January 1989. Commands may order these documents from the ASO Naval Publications and Forms Center, 5801 Tabor Ave., Philadelphia, PA 19120-5099 using NSN 0913-LD-054-7770 and NSN 0691-LD-319-9600 respectively.
2.3.7           CRYPTOGRAPHIC COVERAGE
Key list requirements and restart times for covered broadcast circuits are located in the appropriate CIBs； The EKMS Manager can provide the effective edition of the keying material.
Restart procedures are per applicable CIBs and KAO'S. EKMS 1 (SERIES) contains information on cryptographic systems.
2.3.8           BROADCAST MESSAGE NUMBERING
Each broadcast message is assigned a nine (9) position alphanumeric Broadcast Channel Sequence Number (BCSN) to ensure traffic continuity. The BCSN consists of a four-letter broadcast channel designator and a five digit sequence number, which indicates the number of cumulative transmissions that occurred for the particular channel. This number runs from 00001-99999 and is reset monthly at 010001Z. Should the sequence number exceed 99999 within a given month, the counter will reset to 00001 until the end of the month, and then reset again to 00001 to begin a new month. The BCSN is preceded by the message transmission identification (TI) indicator VZCZC (see paragraph below).
BCSN numbering continuity for overload channels is maintained the same way as above. In a situation where an overload channel is deactivated and then reactivated in the same month, the BCSN will run consecutively from the last number used. The overload channel activation message will indicate the first overload BCSN to be transmitted.
2.3.9           BROADCAST MESSAGE FORMAT
Each message originally transmitted over a broadcast channel that is keyed by FBKS will be formatted as follows.
EXAMPLE
VZCZCPMAA01013
R 220933Z FEB 00 PSN 000207H09
FM JCS WASHINGTON DC
TO USS CHOSIN
INFO USS HUE CITY
USS GETTYSBURG
BT
UNCLAS //N02300//
MSGID/GENADMIN/JCS//
SUBJ/EXAMPLE OF A BROADCAST MESSAGE// REF/A/GENADMIN/CHOSIN/101213ZFEB00//
RMKS/(40 MORE LINES OF TEXT)
PAGE 02 PMAA01013 UNCLAS (REMAINING TEXT) //
BT

#01013
NNNN
Each original broadcast transmission of a message, over either the single or multi-channel broadcast will begin with the Transmission Identification (TI) indicator and BCSN. The TI indicator consists of the characters "VZCZC". The V's purpose is to clear the circuit path of any extraneous characters and the ZCZC is to signal the start of a message indicated by the beginning of format line 2 of the message. Retransmissions will commence with the operating signal ZFG repeated three times.
EXAMPLE
ZFG ZFG ZFG VZCZCPMAA01014
O 220514Z FEB 00 PSN 000472H13 ZNZ1 FM USS SAN JOSE TO USS CALIFORNIA BT
TEXT
BT
#01014
NNNN
Before a message queues to a broadcast channel, FBKS validates delivery requirements specified in format lines 2, 4, 7 and 8.
The system rejects misrouted messages to the DUSC for service action.
To save transmission time FBKS edits each message. Because format lines 2 and 4 are validated by Nova they are not transmitted.
Side routes on format lines 7 and 8 are also validated and removed. Original page lines are removed and F/L 15 is replaced with the BCSN.
Lengthy messages are paged into blocks of 50 lines. Each page block will begin with a page number, BCSN, and the message classification. This is done to enhance a message's readability and ease of reproduction.
Nova assigns every message received an accountability number, called a Processing Sequence Number (PSN). This 6-digit number is included on F/L 5. It is followed by the site's letter identifier and a checksum of the PSN. The first letter of the BCSN and the F/L 5 site identifier will normally be the same. A difference between the two indicates that the screen action should be to the site identified on F/L 5.
Messages retransmitted over a single or multi-channel broadcast in reply to a Broadcast Screen Request (BSR) will begin with the operating signal ZDK repeated three times, followed by the TI indicator and the BCSN. The remainder of the transmission is the actual message beginning with F/L 5.

EXAMPLE
ZDK ZDK ZDK VZCZC PMAA00036
R 162038Z FEB 00 PSN 017677H28 FM COMSPAWARSYSCOM WASHINGTON DC//PMW151//
TO USS ENTERPRISE BT
UNCLAS //N02300//
MSGID/GENADMIN/CSWSC//
SUBJ/BROADCAST MESSAGE FORMAT//
RMKS/THIS IS AN EXAMPLE OF BROADCAST MESSAGE FORMAT//
BT
#00036
NNNN
2.3.10         BROADCAST RECAPS
Every 30 minutes a message summary (RECAP) is transmitted for each active first-run and overload broadcast channel. The RECAP provides a summary of the traffic that was transmitted the previous half hour. RECAP'S are assigned immediate precedence and are queued at the top of the immediate message queue.
A RECAP message for a first-run channel will show the associated overload or rerun channel. Likewise, a RECAP for an overload channel will show the associated first-run channel. Shipboard personnel should note this information each time a RECAP is received. This will help insure all appropriate broadcast channels are being copied.
The text of the RECAP reflects the BCSN, precedence, date—time- group, originator and broadcast addressees for each message transmitted on that broadcast channel. RECAP DTGs are always assigned on the half hour. Part one identifies the message transmitted including precedence, DTG, Originator, and any pertinent Q and Z signals. Part two identifies the specific CSNS that were sent to specific commands. The following depicts the format of a RECAP for the Pacific Overload Broadcast.
EXAMPLE
VZCZCIOCC01019 O 230200Z FEB 00 ZNZ FM FMX PAC HONOLULU HI TO POCC BCST BT
UNCLAS SVC //N00000//

SUBJ： BROADCAST RECAO 230130 FEB 07 — POCC OVERLOAD 一 PMCC FIRST RUN PART ONE
1013      R 220933Z JCS WASHINGTON DC/USS

1014      0 220514Z USS SAN JOSE/USS CALIFORNIA/ZNZ
1015      P 201514Z COMNAVNETOPSCOM WASHINGTON DC/CTF
1016      P 230005Z FLEWEACEN GUAM/ZPW 240001Z FEB00
1017      R 230105Z USS SAN FRANCISCO/COMTHIRDFLT/
1018      CANTRAN PART 2
PMCC BCST
1013       01015 01016 USS CHOSIN
01014
CTF FOUR TWO
01017
BT
#01019
NNNN
BROADCAST SERVICE MESSAGES

 

Broadcast Screen Request (BSR)
BSR is a PROFORMA message designed for fleet broadcast subscribers to request the transmission (ZDK) of messages missed or received garbled on any fleet broadcast. PROFORMA messages should be prepared using the approved message preparation software program. Every message sent over a broadcast channel is retransmitted over the associated rerun channel after a two-hour delay, if the rerun channel is not being used for some other purpose. Broadcast Keying Stations (BKS) generate summary messages every half-hour identifying intended recipients of a particular broadcast number. This helps recipients identify missing broadcast numbers/messages. Prior to sending a BSR to the broadcast station, every attempt must be made to obtain the missed messages from rerun channels, ships in company while underway, or shore communications facilities when in port. Subscribers will ensure each BSR cancels previous outstanding requests and lists all outstanding numbers on the broadcast channel concerned. Ships will send BSR's to the BKS unless otherwise directed.
If a recipient misses 50 or more broadcast numbers, the numbered fleet commander shall be included as an information addressee and a reason for outage should be identified by adding a remarks set to the BSR PROFORMA message. If the request is in excess of 100 total broadcast numbers, separate BSR'S in increments of 50 numbers must be generated. BSR's received with more than 100 Broadcast Screen Numbers (BCSN) will be rejected.
Each BSR will be complete in itself and will include all numbers missing at the time of submission, less missed numbers known not to be addressed to ship's or embarked commander's guard list.
This information is available on hourly FMX generated RECAP summary messages.
Embarked commanders who are assigned a routing indicator (RI) different from the RI assigned to the host ship must be included

when submitting a BSR. Embarked commanders, squadrons, detachments, etc., which share the host ship's or embarked commander's RI will not be included.
If a Broadcast Screen Ship (BSS) is designated prior to an exercise or operation, the BSS is responsible for gathering missed message input for ships in company and submitting a consolidated BSR.
The following format is currently used for submission of BSR'S. Detailed information for drafting BSR'S is available in NTP 4 Supp-2.
Retransmissions in response to BSR'S are only provided to those ships which are addressees (or have embarked commands) addressed in the missing numbers (messages) requested. Retransmissions are transmitted under the original broadcast numbers prefixed with a ZDK pilot.
In the event of an FMX failure which causes the BKS functions to be shifted, instructions will be provided to fleet units concerning BSR submission procedures.
EXAMPLE
RTTUNJSR RUEOMID3463 1191000-UUUU--RHMCSUU.
ZNR UUUUU
R 281000Z APR 00 ZYB FM USS JOHN C STENNIS TO FMX PAC HONOLULU HI BT
UNCLAS //N02790//
MSGID/BSR/STENNIS//
SCRN/USS JOHN C STENNIS /COMCARGRU THREE//
CHAN/PMAA/BSN：00012/BSN：00023/BSN：00050/BSN：00053//
CHAN/PMCC/BSN:00056/BSN:00087//
SCRN/ATKRON FIVE FOUR TWO//
CHAN/PMDD/BSN：000 90/BSN：000 92/BAND：00100-00103/BSN：00113// SCRN/USS JOHN C STENNIS //
CHAN/PMCC/BSN：00075//
PERIOD/2 00001ZJAN2 001/24235 9ZJAN2 001//
BT
#3463
NNNN
Broadcast Screen Summary (BSS)
The FBKS in response to a BSR generates the Broadcast Screen Summary (BSS). The BSR response will originate from the servicing FMX site and will bear the appropriate PLA for the site, i.e. FMX PAC HONOLULU HI. Examples of BSS responses are listed below：
1.  NO MESSAGES FOUND. (MASTER UPDATE AUTHORITY has screened originator BSR and missing messages are of no concern to

	originator.)
2.	FOL	NRS	CANTRAN.
3.	FOL	NRS	ZFK	1/2.
4.	FOL	NRS	ZDK	AT TIMES INDICATED.
5.	FOL	NRS	ZDK	ASAP.
6.	FOL	NRS	ZOV	ASAP.
7.	FOL	NRS	TO BE TRANS WITH NEW NRS.
8.	FOL	NRS	TRANS AT TIMES INDICATED.
9.	ERROR.		(BSR	contains error(s), Unable
	and	resubmit.)

Broadcast Screen Summary Reply Example

 
OTTUZYUW RHOENPM00 9 9 0311030-UUUU--RHMCSUU.
ZNR UUUUU
O 311030Z JAN 00 ZYB FM FMX PAC HONOLULU HI TO USS NIMITZ BT
UNCLAS
MSGID/GENADMIN/FMX PAC//
SUBJ/BROADCAST SCREEN SUMMARY// REF/A/BSR/NIMITZ/311000ZJAN2 001/-/N〇TAL//
RMKS/
1.   ATKRON FOUR TWO
A. NO MESSAGES FOUND.
2.   USS NIMITZ
A.    FOL NRS CANTRAN: PMAA00023.
B.    FOL NRS ZFK 1/2 : NONE.
C.   FOL NRS ZDK AT TIMES INDICATED： PMAA00012/0310930
D.    FOL NRS ZDK ASAP： PMAA00050, PMAA00053, PMCC00053,
3.         USS JOHN C STENNIS
A. FOL NRS ZOV/ASAP：PMCC00075
4.   ERROR/USS NIMITZ/CHAN/PMDD/FIELD 5 INVALID, 99003 PROCESS/CORRECT AND RESUBMIT//
 

Figure 3-3 is the check-off sheet used for keeping a record of broadcast numbers received or transmitted. This form provides for the number received, the classification of the message, and also provides a record of destruction for classified traffic. These forms may be reproduced locally. A similar form is available through supply channels (Stock number 0196-LF-301- 8350).

2.3.12         BROADCAST OFF THE AIR MONITORING (OTAM)
OTAM is a computer-based monitoring system for up to 16 circuits. The fleet centers located at the NCTAMS and selected NAVCOMTELSTA'S monitor the fleet broadcast by receiving the same broadcast copied by fleet units. The monitor copy ensures channel continuity, crypto synchronization, and provides an analytical source for identifying and solving problems.
All broadcast channels transmitting live traffic (including those uncovered) will be monitored off the air to ensure proper operation. Area NCTAMS may assign OTAM responsibilities for individual broadcast channels to stations other than the originating station provided the designated stations can meet the tasking within existing manpower and equipment resources. No more than one station is required to monitor the same broadcast channel except when unusual conditions dictate. Keep NETWARCOM advised of situations involving unusual conditions. Support and residual stations which rekey broadcasts are required to conduct normal quality control of broadcast circuits and where equipment allows, should spot check with OTAM as part of the quality control effort.
Include the term OTAM in the remarks column of the broadcast line item in the station TELCOR Section I summary. Broadcast originating stations and those commands assigned OTAM functions are to include the broadcast monitoring and broadcast transmit equipment in the appropriate sections of the communications operating facility report.
2.4     TYPES OF BROADCASTS
2.4.1           FLEET MULTICHANNEL BROADCAST SYSTEM
The Fleet Multi-channel Broadcast System (MULCAST), provides the means of delivering message traffic to the Fleet. The MULCAST System is a highly flexible system providing global broadcast service to the Fleet via four major communications areas. FBKS keys the MULCAST. The paragraphs below describe the characteristics of MULCAST in terms of its broadcast area, FLTCOMS, operating frequencies, channelization and general operating procedures.
BROADCAST AREA FLTCOM

 

Operating frequencies： MULCAST may be operated on Satellite, Low Frequency (LF), Medium Frequency (MF), High Frequency (HF) and

Ultra High Frequency (UHF) ranges. Consult current CIB'S for operating frequencies.
Due to inherent limitations of HF propagation, the HF component of the MULCAST (when activated) is transmitted simultaneously on several frequencies to permit diversity reception. In some cases, diversity reception overcomes the anomalies of HF propagation and reduces the probability of broadcast interruption. Recipients of the MULCAST can use one of two methods for diversity reception which are：
Frequency of RF diversity in which the information signal is transmitted/received on two separate frequencies simultaneously. Shipboard use of frequency diversity permits uninterrupted circuit operation since fading over two different frequencies will seldom occur at the same time. Polarity diversity uses a vertically and horizontally polarized antenna to copy a single frequency.
A maximum of sixteen channels of information are combined to form the multi-channel broadcast. The multi-channel broadcast transmitted via satellite carries 15 channels of information (channel 16 contains system frame/sync data). Most ships maintaining their own guard are required to copy at least the common channel. If traffic tempo dictates, overload channels are activated to clear first run traffic. When required, overload channels are also used to rekey allied broadcasts in support of U.S. units participating in combined operations. Area CIB's reflect the current assignment of broadcast channels. These broadcasts are normally keyed continuously but require restarts at the beginning of each new CRYPTO day.
Normally all first-run traffic is retransmitted two hours later over the associated rerun channel, i.e., PMAA first-run traffic sent between 1400Z-1500Z will be transmitted over the rerun channel PRAA at 1600-1700Z. Because this procedure allows communications personnel the opportunity to copy broadcast numbers missed during the first transmission, submitting Broadcast Screen Requests (BSR) to obtain lower precedence missed numbers should be delayed until after the rerun transmission (see paragraph 419). If a RECAP message indicates that the missed number (message) is addressed to your ship/unit and the precedence is immediate or higher, BSR action may be necessary sooner.
Once a queue has been depleted on a first-run channel, it and its associated overload channel (if assigned) will commence rerunning messages. The last message transmitted will be the first message rerun. For example, if LMAA01016 was the last message transmitted it would be the first message rerun, followed by LMAA01015, LMAA01014, etc. A channel will revert to a first-run status whenever a new message is received.
2.4.2          WORLD-WIDE TACAMO (WTAC)
TACAMO (Take Charge And Move Out) is a survivable communications link during trans-attack and post-attack phases of conflict. It enables the President and the Secretary of Defense to directly contact submarines, bombers and missile platforms protecting our national security through strategic nuclear deterrence.
2.4.3           USW PATROL (VP) BROADCAST
The nature of USW patrol (VP) aircraft operations requires dedicated transmission of all ground-to-air traffic using the broadcast method. The VP broadcast operating in the HF mode serves as the primary vehicle for delivery of operational messages to aircraft regardless of the aircraft's mission, emission mode or supplemental means for delivery. COMPATWINGSPACINST C2330.1 and the Consolidated Maritime Brief Book provide broadcast operating instructions for the Pacific and Atlantic Ocean areas respectively.
2.4.4           SCI FLEET BROADCASTS
SCI communications utilizes three broadcasts, LMFF, IMNN and PMFF for the sole purpose of providing Over the Air Transfers (OTATs) of COMSEC keying material. These broadcasts are included in each particular fleet area, SSR-1 provided broadcast. Weekly OTATs are issued by UARNOC on the 7^th, 14^th, 21^st, 2 8^th and last day of the month. OTAT messages are sent the day prior to transmission of the OTAT. The OTAT message will contain the listing of the keying material that will be transmitted and the time of transmission.
2.5              MANAGEMENT AND CONTROL SYSTEMS
2.5.1          AUTOMATED DIGITAL NETWORKING SYSTEM (ADNS)
The primary function of the ADNS is to connect Navy shipboard networks to other ship and shore networks for transferring Internet Protocol (IP) data of various classification levels. The shipboard user can connect to the external networks of other Navy platforms and facilities and the Wide Area Networks (WANs) provided by the Defense Information Systems Agency (DISA).
The ADNS system is designed to allow network enclaves to route (IP) data over multiple RF mediums. The RF services include, but are not limited to, Super High Frequency Defense Satellite Communications System (SHF DSCS), Extremely High Frequency/Medium Data Rate (EHF/MDR), Extremely High Frequency/Time Division Multiple Access (EHF/TDMA) Interface Processor (EHF/TIP), International Marine/Maritime Satellite (INMARSAT B), SHF Commercial Wideband SATCOM program (CWSP) (which will be replaced by the Commercial Broadband Satellite Program (CBSP) beginning in 2008) and pier connections. The ADNS system provides Wide Area Network (WAN) connectivity to the shore by passing IP data over available RF mediums using Point-to-Point Protocol (PPP) for link establishment and maintenance. By dynamically routing IP data using Open Shortest Path First (OSPF), the ADNS system can choose which RF link to use to reach the shore.
RADIO COMMUNICATIONS SYSTEM (RCS)
The Radio Communications System (RCS) consists of several exterior communications subsystems which, in combination, provide all exterior communications requirements for the ship with the exception of the Special Intelligence Communications requirements. The RCS subsystems are turnkey installations and consist of the following subsystems： High Frequency Communications System, Very High Frequency Communications System, Ultra High Frequency Line-of-Sight Communications System, Ultra High Frequency Satellite Communications System, Extremely High Frequency Satellite Communications System, Super High Frequency Satellite Communications System, Communications Support Segment, Naval Modular Automate Communications System II, and the Bridge to Bridge Communications System.
NAVY ORDERWIRE TERMINAL (NOW)
NOW is A PC-based system that supports up to four full duplex circuits using Navy Orderwire software in conjunction with two Frontier Communications boards. The system replaces Teletype equipment formerly used on four orderwires and has message storage and retrieval capabilities as well as an editor for message preparation. Circuit logs may also be stored and retrieved. An optional printer may be attached for message copies and logs. This circuit is not certified and will not be used to pass traffic except as a last resort.
2.5.4          AUTOMATED NETWORK CONTROL CENTER / AUTOMATED TECHNICAL CONTROL (ANCC/ATC)
The ANCC and ATC are functionally identical except for size. ANCC/ATC replaces manual patch and test facilities ashore with a fully redundant computer-controlled switching and circuit monitoring system. This system provides the ability to reconfigure equipment interconnectivity and perform circuit monitoring for out-of-tolerance conditions in advance of circuit outages. At deployed locations, this system supplies 98 percent of voice, video, and data connectivity. Failures result in major C4I disruption of services to and from the operating forces in an entire communications area.
2.5.5           MULTI-CIRCUIT PATCH PANEL (MCPP)
The multi-circuit patch module provides for equipment interfaces requiring a database (DB)-type interface. It contains two non­powered (without LEDs) multi-circuit patch panels and a quick connect panel QCP. Two of the patch panels contain 17 patch modules while the others contain 16 patch modules. The two containing 17 patch modules have a test module with a DB 25-pin connector and standard modular patch jack. The two containing 16 patch modules have a test breakout module for connecting individual signals. Each patch module has line, equipment, and monitor appearances. The common signal interface to a patch module will be electronic industry association (EIA) standard RS- 232 for unbalanced and RS-53 0 for balanced. However, the following common interfaces RS-232/-423/-422/-530 or MIL-STD-188- 114 can be accommodated. Up to eight RS-423/-422 37-pin interfaces and twelve RS-232/-530 25-pin interfaces can be selectively pinned out using the QCP, thus eliminating a need to fabricate special cables when deployed. Interfaces from the multi-circuit module may also be routed through the high-speed COMSEC case for encryption/decryption. Two multi-circuit modules are provided with each TCTC package.
All Transit Case Technical Control (TCTC) modules may be interconnected using one-for-one standard DB 25- or 37-pin connector cables available from most telecommunications companies. Depending on the TCTC module, a number of female connectors on a rear signal entrance panel (SEP) are available for interfacing between modules. This allows interfacing with equipment using one-for-one cables to facilitate rapid set-up and interface. Connectors on the module SEPs are identified by the signal interface convention to which they conform； i.e., rS- 232/423/422/530 and MIL-STD-188-114. To accommodate equipment- specific pin-outs, signal conversions are accomplished in the TCTC module using quick connect/disconnect panels, thus eliminating the need to fabricate special cables when deployed. CJCSM 6231.01B defines the joint communications network model that the TCTC supports. A deployed JTF in a bare-base environment provides the basis for this model. The model can be changed to meet specific operational requirements. Internodal communications provides connectivity among DISN, JTF headquarters, and service component headquarters and their forces, along with supporting elements such as the JSOTF and its subordinate forces. The Air Force, Army, Navy, and Marines have component headquarters and forces. This network links the deployed locations by satellite and microwave troposcatter/line of sight. This transmission media supports the extension of common-user transports consisting of JWICS, NIPRNET, SIPRNET, record communications (AUTODIN and DMS), VTC, and other special- purpose circuits. The TCTC is capable of extending all of these transports or communication services.
SA2112(V) (SAS)
The heart of the radio transmitter and receiver distribution system is the SA-2112 single audio system (SAS). The SA-2112 secure switching unit, commonly referred to as the SVS or "coke machine", is the key element in the SAS. The SAS provides the ship with an integrated secure (cipher)/nonsecure (plain) R/T voice system. SAS features allow remote operating positions to select either cipher or plain voice operations without reconfiguring the existing system. It also provides automatic switching between remote operating positions and radio sets or
crypto equipment, centralized control and monitoring of the system, and a built-in-test (BIT) capability.
2.5.7           TIMEPLEX LINK 2+
The LINK/2+ has become the primary full or half-duplex, first level multiplexer for Navy tactical SHF communications. LINK/2+ is an intelligent transmission resource manager (TRM) currently supporting Navy SHF and commercial operations, providing high- performance networking capabilities for facilities with large I/O requirements. It is a multi-system high-capacity networking device for voice, data, and imagery communications transmissions over T-1/2.048 Mbps data rate (European)(E1) or lower speed facilities. It provides smart multiplexing, bandwidth efficient management and full network management capabilities.
The LINK/2+ incorporates a modular design for enhanced flexibility, reliability, and improved network performance. Navy SHF uses a basic 18-slot chassis, with the capability of an 18- slot-expansion chassis (two-nested) system. It is capable of processing digital data, voice (voice compression), and video synchronous, asynchronous, isochronous, asymmetrical (different transmit and receive speeds on the same channel), and simplex signal processing.
The LINK/2+ is capable of operating 12 trunks at aggregate data rates of 4.8 Kbps to 2.048 Mbps each (not to exceed 7 T-1's, each at 1.544 Mbps).
NETWORK SERVICES AND ARCHITECTURE
ROUTING ARCHITECTURE
Routing involves the forwarding of IP packets across a network to the intended destination IP address. Routing occurs at Layer 3 (the network layer) of the OSI reference model. To determine the optimal path for a packet to travel, routing protocols use metrics. To assist the process of determining the path a packet will travel, routing algorithms create and maintain routing tables (list of associations used to decide the next router a packet should be sent to reach ultimate its destination).
2.6.2       DISN TRANSPORT SERVICES
The Defense Information System Network (DISN) provides a variety of voice, video and data transport services for classified and unclassified users in the continental United States (CONUS) and overseas (OCONUS). DISN supports customer requirements from 2.4 Kbps to 155 Mbps (OCONUS) and 2.5 Gbps (CONUS). Its best-value network solutions include inherent joint interoperability, assured security, redundancy, high reliability/availability, 24/7 in-band and out-_of-band network management, engineering support and customer service.
DISN transport services are available to all Department of Defense (DoD) agencies and military services, as well as other federal government agencies. Services can be ordered through the telecommunications control officer (TCO), who will validate requirements and verify funding authorization.
DoD Teleport System
The Defense Information Systems Agency (DISA) is implementing the Department of Defense (DoD) Teleport System. The system will integrate, manage, and control a variety of communications interfaces between the Defense Information System Network (DISN) terrestrial and tactical satellite communications (SATCOM) assets at a single point of presence.
The system is a telecommunications collection and distribution point, providing deployed warfighters with multiband, multimedia, and worldwide reach-back capabilities to DISN that far exceed current capabilities. Teleport is an extension of the Standardized Tactical Entry Point (STEP) program, which currently provides reach-back for deployed warfighters via the Defense Satellite Communications System (DSCS) X-band satellites.
This new system provides additional connectivity via multiple military and commercial SATCOM systems, and it provides a seamless interface into the DISN. The system provides inter- and intra-theater communications through a variety of SATCOM choices and increased DISN access capabilities.
The system will be implemented in three phases：
1.   Generation One - Currently being implemented. Generation One (FY02-08) architecture adds capabilities to a subset of existing STEP sites. It will provide satellite connectivity for deployed tactical communications systems operating in X-band (DSCS and follow-on X-band satellites), commercial C- and Ku- bands, Ultra High Frequency (UHF), Extremely High Frequency (EHF) SATCOM and initial Ka-band capabilities.
2.   Generation Two - This generation (FY 06-08) consists of implementing additional Ka-band terminals and a NETCENTRIC capability. The Ka-band terminals will provide interfaces to the Wideband Global System (WGS) program, which will provide Ka-band and X-band coverage with throughput far exceeding the current DSCS satellite constellation.
3.   Generation Three - This Generation is currently undefined and funding has not been identified. A capabilities development document is in development and a funding approach will be sought by the Joint Capabilities Board. For more information Email: 
GIG Enterprise Services
The Defense Information Systems Agency's (DISA) Global Information Grid Enterprise Services Engineering (GE) directorate plans, engineers, acquires and integrates joint, interoperable, secure global net-centric solutions satisfying the needs of the warfighter and develops and maintains a first-class engineering workforce to support the needs of DISA's programs. GE's core competencies include disciplined IT end-to-end systems engineering, security expertise for the Global Information Grid, leveraging commercial-off-the shelf products and services to solve joint and coalition needs and provide value added, trustworthy global net-centric solutions. Contact： GES Project Office at
Global Combat Support System (GCSS) Combatant Commanders/ Joint Task Force (CC/JTF)
GCSS (CC/JTF) is an initiative that provides end-to-end visibility of retail and unit level Combat Support (CS) capability up through National Strategic Level, facilitating information interoperability across and between CS and Command and Control functions. In conjunction with other Global Information Grid elements including Global Command and Control System-Joint, Defense Information Systems Network, Defense Message System, Computing Services, and Combatant Commands/Services/Agencies information architectures, GCSS (CC/JTF) will provide the information technology capabilities required to move and sustain joint forces throughout the spectrum of military operations.
GCSS (CC/JTF) supports the Combatant Commanders and their assigned Joint Task Forces by providing access to comprehensive logistics information from authoritative data sources. This access provides the warfighter with a single, end-to-end capability to manage and monitor units, personnel and equipment through all stages of the mobilization process. By providing access to high-level integrated information, GCSS (CC/JTF) enhances the ability of Combatant Command and JTF Commanders to make timely, informed decisions based on the near real-time or predicted status of his resources.
Mission
Provide end-to-end information interoperability across combat support and command and control functions to support the Combatant Command & Joint Task Force Commanders.
GCSS (CC/JTF) Warfighting Capabilities
1.  Provides dynamic access to command & control, intelligence, and logistics data via a single gateway.
2.  Provides browser-based, PKI-enabled capabilities on the SIPRNet and CAC-enabled capabilities on the NIPRNet.
3.  Provides joint logistics applications via a single sign on.
4.  Single, Mobility System, Global Transportation, Network, Intelligent Rail/Road Information Server, Asset Visibility, In-transit Visibility, Integrated Data Environment.
5.  Consuming web services from NGA's mapping capability (Adopt before you buy, Buy before you Create).
6.  Provides access to NCES' E-Collab from GCSS (CC/JTF).
7.  Provides permission-based, knowledge management system (KMS) for file-sharing within and across combatant commands.
8.  Provides ability for end-users to run reports and export to other formats, e.g., briefing, spreadsheet, .pdf.
9.  Provides a Watch Board to monitor critical items.
10. Provides a modular, net-centric, service oriented
environment for agile, flexible, rapid development and
delivery of critical capability.
11. Provides a Civil Engineers Modeling tool： Joint
Engineering Planning and Execution System (JEPES).
2.6.3         COMMUNICATIONS WITHIN DISN DATA SERVICES NETWORKS
CONNECTIONS TO THE INTERNET
1.  All bureaus and posts having access to OpenNet are required to establish Internet connectivity through OpenNet Plus. If OpenNet service is available to the bureau/post, the Department will no longer fund or approve Dedicated Internet Network (DIN) service unless the bureau or post has a valid waiver to implement a DIN.
2.  A post may have a contract with an Internet Service Provider (ISP) to provide bandwidth for contingency and VNet (also know as Virtual Private Network (VPN)) provided and managed by IRM/OPS/ENM/ND. This is to provide the post with an alternate route for connectivity back to the Open Net infrastructure and does not require a waiver.
3.  Information Resource Center (IRC) public access terminals have been granted a waiver from this policy； i.e., ODI (Overseas Dedicated Internet) LANs may continue to provide Internet access and other Public Diplomacy services to the public. Local networks used as test, development, web hosting, and research environments may also connect locally to the Internet, but can only do so after receiving a waiver. These Local Area Networks (LANs) are not to be linked to
OpenNet Plus or used by employees to carry out Department business transactions. Bureau/post must terminate all unauthorized use of ODI LANs no later than 90 days after OpenNet Plus is implemented at the bureau/post.
4.  The Department realizes that there may be exceptions to the requirement for accessing the Internet via the OpenNet.
Posts and bureaus may request a waiver to this policy. The IT Change Control Board (CCB) will review such requests on a case-by-case basis.
REQUESTING A WAIVER TO THE INTERNET CONNECTION POLICY
A Bureau/post requesting authorized continued use of a Dedicated Internet Network (DIN) connection must submit the DIN access waiver request. All DIN solutions must comply with the Department's standards and FAM guidance. Provide the following information when submitting the waiver request：
1.  Post or bureau name.
2.  Post or bureau point of contact, e-mail address, and telephone number.
3.  Location serviced by DIN.
4.  Type of Internet access service (DSL, dial-up, other).
5.  Configuration details (number of connections, users, rooms to be served).
6.  Purpose of the service.
7.  Reason requirement cannot be satisfied through OpenNet Plus (for example： Protocol is not available through OpenNet Plus—website not accessible).
8.  What post/bureau is doing to reduce risks (i.e. firewalls, virus protection).
9.  Projected costs.
10.    Timeframe of exception.
Submit DIN Access Waiver Requests by e-mail to “IT CCB Management” or by telegram or memorandum to the IT CCB Change Manager, IRM/OPS/ENM/NLM/ECM. The IT CCB Change Manager will conduct an abbreviated review with relevant IT CCB primary review authorities and will ensure the request appears on the next IT CCB meeting agenda for consideration and decision.
If a request for a waiver is denied, the bureau/post may send an appeal to the Chief Information Officer for final decision. If a bureau/post's network is connected to the Internet outside of OpenNet Plus and without the signed DIN waiver, the bureau/post is in conflict with security guidelines. If unauthorized Internet connections are detected, the responsible office will be instructed to disconnect them.
SWITCHES AND ROUTERS
A network switch is a computer networking device that connects network segments. Low-end network switches appear nearly identical to network hubs, but a switch contains more “intelligence” （and a slightly higher price tag) than a network hub. Network switches are capable of inspecting data packets as they are received, determining the source and destination device of that packer, and forwarding it appropriately by delivering each message only to the connected device it was intended for, a network switch conserves network bandwidth and offers generally better performance than a hub.
A router is a device that extracts the destination of a packet it receives, selects the best path to that destination, and forwards data packets to the next device along this path. They connect networks together； a LAN or WAN for example, to access the Internet. Some routers are available in both wired and wireless models.
2.6.5          UNCLASSIFIED BUT SENSITIVE INTERNET PROTOCOL NETWORK
(NIPRNET)
NIPRNET is a global long-haul IP based network to support unclassified IP data communications services for combat support applications to the Department of Defense (DoD), Joint Chiefs of Staff (JS), Military Departments (MILDEPS), and Combatant Commands (COCOM). Provide seamless interoperability IP services to customers with access data rates ranging from 56Kbps to 1.0Gbps via direct connections to a NIPRNET router, remote dial­up services (56Kbps), services to the Tactical community via ITSDN/STEP sites, and access to the Internet.
2.6.6         SECRET INTERNET PROTOCOL NETWORK (SIPRNET)
SIPRNET is the DoD's largest interoperable command and control data network, supporting the Global Command and Control System (GCCS), the Defense Message System (DMS), collaborative planning and numerous other classified warfighter applications. Direct connection data rates range from 56Kbps to 155Mbps. Remote dial­up services are available to 19.2Kbps.
AUTHORIZED SERVICE INTERRUPTION (ASI)
DISA policy requires that the best possible communications service be provided to warfighters and users of the Global Information Grid (GIG). This correlates to the availability of communications equipment and facilities. Periodic maintenance varies from the removal of equipment to a complete shutdown of a
DISN facility. These scheduled interruptions are generally known in advance and every effort must be initiated to provide continuity of service to the users during the scheduled interruptions. The DISA CONUS ASI Manager is the approval authority for routine service interruption requests on DISN stations, nodes, links, trunks, and circuits. The DISA CONUS Commander is the sole authority for approving/canceling ASIs with the CONUS Theatre. Cancellations and rescheduling will be accomplished by the DISA CONUS ASI Manager in conjunction with the guidance provided by the DISA CONUS Commander in coordination with the Global NetOps Center (GNC).
Types of ASIs：
Emergency Service Interruption (Real time operational impact only)： Service interruptions to correct hazardous or degraded conditions where loss of life/property could occur through lack of immediate action. No prior coordination or user release is required (reference DISA Circular 310-70-1, c7.3.4.7). The facilities involved must notify users when time permits and report the circumstances to the NOC Controller or SCO/Watch Officer as soon as possible. These situations must also be reported to the appropriate DISA and O&M elements as time permits.
Urgent Service Interruptions：
Service interruptions that do not qualify as an emergency but are requested inside the 21-day prior notice period. A justification to waive the 21-day prior notice requirement must accompany the initial request. The DISA CONUS ASI Manager will stringently review the request and justification. The only exception to the 21-day notice policy is for the P4035 Optical contractor.
NOTE： Lack of coordination or resources is not a valid justification. It is important to note that urgent requests that do not have a valid 21-day justification will be handled as routine requests. The Commander, DISA CONUS has sole authority to approve urgent ASIs once customer concurrence is received.
Routine Request:
A service interruption in which the request is received no later than 21 days prior to the requested scheduled interruption. The requesting O&M elements must notify the DISA CONUS ASI manager no later than 21 days in advance of the requirement and request tentative approval. The only exception to the 21-day notice policy is for the P4035 Optical contractor. Facilities must submit times/dates avoiding peak traffic hours (1100z - 1800z) during the weekday. However, if a CONUS ASI will affect a real time mission in another AOR, the ASI will be scheduled to accommodate that mission.
Upon completion of the ASI, the appropriate maintenance activity will notify the NOC Controller or SCO/Watch Officer. The GNSC SCO will provide verbal notification to the GNC SCO of the ASI status.
Extension of an Ongoing Approved ASI - The GNC has sole authority to approve/disapprove ASI extensions for inter-theater systems supporting Europe, Pacific, and CENTCOM arenas. The GNSC SCO has authority to approve/disapprove extensions on the recommendation of the NOC Controller or SCO/Watch Officer of up to 1 hour to complete ongoing scheduled ASIs within CONUS. The GNSC SCO will notify the GnC SCO that an extension was granted. Extensions beyond 1 hour require DISA CONUS Commander approval and will be coordinated with the GNC SCO after mission impact has been jointly assessed by the GNSC and GNC SCO.
If an ASI has to be cancelled, the Node Site Coordinator or NOC Controller or SCO/Watch Officer will notify the DISA CONUS ASI Manager immediately or the GNSC SCO (after hours). The ASI Manager will notify the users by sending a cancellation message and the reason for cancellation to the field. If the cancellation comes immediately prior to the maintenance, then telephonic notification between the applicable NOC and users is authorized. An official cancellation/reschedule message will be sent as soon as possible.
CARRIER RATES (T1, E1, OC3, OC12, ETC)
A carrier signal is a frequency in a communications channel modulated to carry analog or digital signal information. For example, an FM radio transmitter modulates the frequency of a carrier signal and the receiver processes the carrier signal to extract the analog information. An AM radio transmitter modulates the amplitude of a carrier signal.
-T1： A dedicated connection supporting data rates of 1.544Mbps. A T-1 line actually consists of 24 individual channels, each of which supports 64Kbps. Each 64Kbps channel can be configured to carry voice or data traffic. T-1 lines are a popular option because they allow for Internet connectivity. The Internet backbone itself consists of faster T-3 connections.
-E1： Ten years following the success of the T1, Europe decided they wanted their own digital transmission technology and subsequently developed the E1. An E1 connection supports 2.048Mbps. The E1 and T1 can be interconnected for international use. Europe has E carrier ratings from E1 to E5 with E5 supporting 565.148Mbps.
-T3： A dedicated connection supporting data rates of about 43Mbps. A T-3 line actually consists of 672 individual channels, each of which supports 64Kbps. T-3 lines are used mainly by Internet Service Providers (ISP) connecting to the Internet backbone and for the backbone itself.
-OC： Is short for Optical Carrier, used to specify the speed of fiber optic networks conforming to the SONET standard. Below are the speeds for common OC levels：
OC = speed

OC-1 = 51.85 Mbps OC-3 = 155.52 Mbps OC-12 = 622.08 Mbps OC-24 = 1.244 Gbps OC-48 = 2.488 Gbps OC-192 = 9.952 Gbps OC-255 = 13.21 Gbps
IT-21
IT-21 is an information transfer strategy that provides Network Connectivity capable of Voice, Data and Video for afloat units. It provides access to NIPRNET, SIPRNET and JWICS, and supports all tactical and non-tactical mission areas. IT-21 uses Commercial Off the Shelf (COTS) Technology to keep ships updated with the most modern equipment. The goal of IT-21 is to provide an integrated, coordinated, end-to-end warfighting capability.
INTEGRATED SHIPBOARD NETWORKING SYSTEM (ISNS)
ISNS is a collection of workstations, servers, switches and routers, both at the Unclas and Secret levels that connect numerous systems like GCCS-M, NTCSS, SAMS, OPINS etc., to external routers like ADNS. It provides Navy ships with reliable, high-speed SECRET and UNCLASSIFIED Local Area Network (LAN)s； Network infrastructure (switches routers, and drops to the PC)； Basic Network Information Distribution Services (BNIDS)； Access to the DISN Wide Area Network (WAN)； Secure and Non-secure Internet Protocol Router Network -SIPRNET and NIPRNET, used by other hosted applications (i.e. NTCSS, GCCS-M, DMS, NSIPS,
NAVMPS, TBMCS, and TTWCS) and enables real-time information exchange within the ship and between afloat units, Component Commanders, and Fleet Commanders. Figure 2-6 depicts a generic ISNS architecture.

Generic ISNS Architecture
(ATM/GigE/Fast Ethernet)

 

2.6.9.2           NAVAL TACTICAL COMMAND SUPPORT SYSTEM (NTCSS)
NTCSS' goal is to provide tactical automated support for maintenance, supply, financial, material and personnel administrative matters. Using IT-21, the Navy-Marine Corps Intranet (NMCI) communication links, and COTS software, NTCSS hopes to achieve bi-directional database replications. Replicating administrative information will reduce the warfighter's workload.
FLEET NETWORK OPERATIONS CENTERS (FLTNOC)
Naval shore communications has evolved from a series of shore based radio stations to a highly sophisticated communications infrastructure. The requirement to support
isolated

integrated voice, video, and data has increased the complexity of a typical communications shore station. Consequently, The Naval Computer and Telecommunications Area Master Stations (NCTAMS) were developed to provide operational direction and management oversight to all subordinate telecommunications system users.
The IT-21 FLTNOCs provide a number of critical Internet Protocol (IP) services to the Fleet (both deployed and pier side) and act as regional gateways to the Defense Information Systems Network (DISN) IP networks in each of their respective Areas of Responsibility (AOR). This is accomplished through the use of a flexible network architecture that can meet unique needs of the different regional forces. The FLTNOCs were originally established as independent data communication systems that only serviced units within specific coverage areas.
The nomenclature for FLTNOCs is AN/FSQ-2 06. The Navy currently has four sites designated as IT-21 FLTNOCs'： European Central Region Network Operations Center (ECRNOC) NCTS Naples Italy, Indian Ocean Region Network Operations Center (IORNOC) NCTS Bahrain, Pacific Region Network Operations Center (PRNOC) NCTAMS PAC and Unified Atlantic Region (UARNOC) NCTAMS LANT. The four IT-21 FLTNOCs are geographically dispersed around the world to service deployed users, provide the entry points for Navy Tactical Satellite Systems and also operate and maintain one or more Defense Satellite Communications Systems (DSCS) terminals. Each IT-21 FLTNOC is typically responsible for providing services to Fleet users located in their corresponding AOR. Current technology provides the ability for a unit to be terminated via satellite RF and terrestrial paths at almost any FLTNOC, regardless of geographical location. FLTNOCs are designed to provide IP services to Fleet IT-21/Integrated Shipboard Network System (ISNS) and deployed ground forces. All are capable of flexibly providing IP services based on unit's satellite RF capabilities including multiple simultaneous RF paths using Automated Digital Network System (ADNS), Automated Digital Multiplexing System (ADMS) or legacy.
The current IT-21 FLTNOC network architecture operates as individual ingress and egress points for Forward Deployed Naval Forces (FDNF) within their specific AOR to provide connectivity to the DISN. Connectivity to the IT-21 FLTNOC from the FDNF afloat platforms is primarily done via the ADNS, which uses available satellite communications systems to enable ship-to- shore data connectivity. Exceptions to this configuration exist, dependant upon the individual mission of the FDNF unit or IT-21 FLTNOC, and are handled on a case-by-case basis. Each IT-21 FLTNOC provides local back-up and restore services via the Network Attached Storage (NAS) and the Out of Band Network, but does not provide for off-site backup and restore services. Figure 2-7 provides a list of baseline equipment for the IT-21 FLTNOC per enclave.

NOC Equipment	Description/Use
Premise Router	Connection point for each NOC to the DISN network.
Outer Security Screening Router (OSSR)	Security filtering for outside the firewalls. Provides load balancing for the Bastion Hosts via VLAN with ISSR.
Firewalls	Bastion hosts. Provides packet filtering, application and layer 4- proxy services.
Inner Security Screening router (ISSR)	Security filtering inside the firewalls. Provides load balancing for the Bastion Hosts via VLAN with OSSR.
Service Switch	Load balances internal DNS, Email, virus scan and web services.
Virus Scanners	Scans inbound and outbound Email and attachments for viruses.
DNSMail Servers	DNS and Email (SMTP) store and forwarding services.
Fleet Router	Serial and IP connectivity to the ADNS network and IT-21 FLTNOC RF (legacy serial) connectivity.
Tunnel Router	Generic Routing Encapsulation (GRE) tunneling services to the Fleet in order to establish NIPRNet Open Shortest Path First (OSPF) adjacencies across the ADNS network.
Network Encryption System (NES) Inline Network Encryptor (INE) Tactical Local Area Network Encryptor (TACLANE)	Encryption devices.
Dial-in switch	Provides in-line connectivity to the Fleet Router
POTS and Integrated Services Digital Network (ISDN) dial-in Routers	Provides dial-in services over telephone or ISDN lines.
Management Switch	Provides connectivity for management devices

Figure 2-7 NOC Core Equipment

 
Figure 2-8 depicts a simplified topology of the current IT-21 FLTNOC architecture and displays only the core equipment for a single enclave (from the Premise Router to the Fleet Router). For the sake of brevity, server subsystems are indicated as Service Suites and do not display the correct number of servers. For example, each IT-21 FLTNOC has at least five DNS Mail servers but is displayed as a single Mail/DNS Suite. Other suites that make up the IT-21 FLTNOC are the Firewall, Virtual Private Network (VPN), Intrusion Detection, Virus Scan, and Web Cache suites. The Premise Router is the ingress and egress Point of Presence (POP) for the IT-21 FLTNOC to the DISN and is considered an untrusted interface. The Fleet Router is the ingress and degree POP to the ADNS network, and is considered a trusted network. This trusted network is the user side of the network system. Also note the External DNS Suite in the below diagram. Fleet NOCs use a feature called Split Horizon DNS. This is used to provide different DNS query answers to requests initiated outside the enclave. If the DNS zone is active internally (inside a FLTNOC enclave), the DNS/Mail Suite provides the actual answers to a DNS query that can associate an IP address to a ship if the query is initiated from inside the enclave. To minimize configuration changes when ships traverse from one AIR to another, the IT-21 FLTNOCs utilize secondary IP addresses called Virtual IPs (VIP), which are duplicated between each IT-21 FLTNOC. Using VIP addresses helps to simplify configuration management and obviates configuration changes to the ship networks or servers for INCHOP/OUTCHOP. VIPs are used for DNS forwarding, Simple Mail transfer Protocol (SMTP) relay and Network Time Protocol (NTP).
All unclassified voice and IP data traversing the classified enclave for ship and shore commands is encrypted using a NES 4001A, INE KG-235 or a TACLANE KG-175.

INCHOP/OUTCHOP
To obtain IP services from a FLTNOC the following criterion must be met：
1.  Must have a valid Interim Authority to Operate (IATO) or Authority to Operate (ATO) obtained from NETWARCOM Designated Approving Authority (DAA). The unit Information Assurance Manager (IAM) can provide guidance on validating or obtaining an (I)ATO.
2.  Submit an IP services request message in accordance with Global Communications Information Bulletin (GCIB) 3A.
3.  If service will be provided via satellite communications link, a valid Satellite Access Authorization (SAA) for the intended satellite RF path is required.
The current system allows Fleet units to transit between AORs without making configuration changes to their ISNS equipment.
This is facilitated by default configurations in the ADNS and the ISNS that utilize the IT-21 FLTOCs VIP address scheme. With the exception of physical path connectivity, the gaining FLTNOC drives the Change of Operational Control (CHOP) process. Once the satellite communications link has been terminated at the gaining Technical Control Facility (TCF, the IT-21 FLTNOC will enable the Fleet unit(s) DNS zone on the internal DNSMail servers. All zone
changes through the entire INCHOP/OUTCHOP process are accomplished by using either the NOC management web interface of the DNSMail servers command line. The Fleet unit(s) IP addresses are then added to the “trusted networks” table on the Navy Firewall Security System (NFSS). The Fleet unit(s) homeport IT-21 FLTNOC, which is authoritative for their DNS zone resolution, will be notified by the gaining IT-21 FLTNOC to direct the Fleet unit(s) external Mail Exchanger (MX) record to the gaining IT-21 FLTNOC. After the gaining IT-21 FLTNOC has verified IP connectivity for the fleet unit(s), their losing IT-21 FLTNOC is notified to deactivate the Fleet unit's DNS zone(s) on their DNSMail servers. Service verification is accomplished by a test email from the IT-21 FLTNOCs domain to the Fleet unit(s) domain (i.e., a successful email transfer between ior.navy.mil and Washington.navy.mil). The only exceptions are for embarked units that must have a CHOP in and out of the Navy IT-21 FLTNOCs (e.g. Marine Expeditionary Units (MEUs) that move from Navy and Marine NOCs)). Additionally, the gaining IT-21 FLTNOC is also responsible for ensuring the unit's IP address Classes Inter­Domain Routing (CIDR) block is being advertised via the IT-21 FLTNOC connection to DISN.
2.6.9.3.2           IT21 FLTNOC SECURITY
The security posture for each IT-21 FLTNOC is independently administered but centrally governed by the Chief of Naval Operations (CNO)/NETWARCOM Unclassified Trusted Network Protect (UTN Protect) firewall policy. Use and enforcement of this policy is mandated by CNO and NETWARCOM security policies. IT-21 FLTNOCs are also tasked with implementing IP block lists and DNS black hole lists as promulgated by Navy Cyber Defense Operations Center (NCDOC).
2.6.9.3.3           CUSTOMERS AND SUPPORT
The following section details the personnel who are currently involved in the day-to-day operations of an IT-21 FLTNOC. There are several types of customers in the IT-21 FLTNOC environment. The customers utilizing satellite or pier connectivity for IT-21 FLTNOC access represent the Fleet users. Additionally, there are embarked units such as air wings and command staff who also utilize the ship and IT-21 FLTNOCs assets for services. It is also important to note that the NCTAMS and/or NCTS may be serving local customers that do not fall within the IT-21 FLTNOC Program, but require service.
The IT-21 FLTNOCs utilize a multi-layered support concept. Each support tier is discussed in further detail below：
1.  Tier One - Provided 24/7 by the active duty Watch
section. This support includes troubleshooting ship-to- shore and intra-NOC communications and acts as the primary resource for IT-21 FLTNOC operations. Daily
configuration changes and maintenance of the system are also performed.
2.  Tier Two 一 System Administrators are responsible for the providing the highest state of operational readiness and availability of the IT-21 FLTNOC to the Fleet.
3.  Tier Three - Provided by the Fleet Systems Engineering Team (FSET) engineers which provide specialized system technical support, engineering assistance, and on site training for all NCTAMS/NCTS personnel.
4.  Tier Four - SPAWARSYSCEN Charleston acts as the primary engineering activity for IT-21 FLTNOC development and provides In-Service Engineering Activity (ISEA) support for the FSETs, NCTAMS, NCTS and other Fleet services. The ISEA also provides logistics for equipment replacement, testing, and training, and as well as hardware and software upgrades for all IT-21 FLTNOCs. The ISEA contacts and interfaces with commercial off-the-shelf (COTS) and government off-the-shelf (GOTS) vendors as necessary for technical support.
2.6.9.3.4       NAVY REGIONAL NETWORK OPERATIONS AND SECURITY CENTER (NAVRNOSC)
The ultimate goal is to migrate from the current four Fleet NOCs concept into expanded roles within NAVRNOSCs. ECRNOC and IORNOC will eventually be collapsed and UARNOC and PRNOC will remain essential elements within RNOSC East and RNOSC West respectively. While they will continue to support the service provider functions of the NCTAMS in addition to managing their portion of the Navy Enterprise Network (NEN), they will also provide virtual views of the enterprise at the strategic, operational and tactical levels. The NAVRNOSCs serve as the technical arm for the Navy in aggregating the elements of Network Operations (NetOps) including Enterprise Management (EM), Network Defense (ND), and Content Management (CM), which supplements Situational Awareness (SA) and Command and Control (C2), employed to operate and defend their portions of the NEN. The NAVRNOSC provides network and system status, performance and ND events from outlaying CONUS and OCONUS elements including the OCONUS Navy Enterprise Network (ONE-NET), IT-21, Network Operations Centers and other systems.
The NAVRNOSC will monitor and control faults, configuration accounting, performance and security of the NEN elements for which they have operational responsibility. The NAVRNOSC will coordinate closely with, and provide users and higher echelons with network status reports and access to real-time data. Additionally, the NAVRNOSC will maintain records pertaining to customer information, local tier control center and site coordinator contact information, network resources, faults and
outages. NAVRNOSC operators will have the capability to remotely manage and control lower echelon systems through the Enterprise Network Management System (ENMS). ENMS has a suite of EM, ND, CM, C2 and SA tools that can be leveraged to provide a common NAVRNOSC operational picture to the Navy Global Network Operations and Security Center (NAVGNOSC).
2.6.9.3.5       PROGRAM EXECUTIVE OFFICE, COMMAND, CONTROL, COMMUNICATIONS, COMPUTERS AND INTELLIGENCE (PEO C4I)
INTELLIGENCE (PEO C4I)
PEO C4I is the program manager for the NOC system and as such is responsible for its life cycle management. As the acquisition agent, PEO C4I is accountable for cost, schedule, and performance. Two program offices within PEO C4I have responsibility for different subsystems. PMW 160 has program management responsibility for the Information Assurance (IA) product suite and PMW 790 has responsibility for the rest of the equipment. Once deployed and fielded, the architecture is supported and maintained with NCTAMS/NCTS personnel. SPAWARSYSCEN Charleston provides technical oversight and engineering support as directed by the PMWs.
2.6.10       NAVY MARINE CORPS INTRANET (NMCI)
The Navy/Marine Corps Intranet (NMCI) was developed to procure and manage information technologies (IT) for the Navy at the enterprise level. NMCI is a partnership between the Navy and industry whereby industry provides IT services purchased by individual Navy commands. The key point is that the Navy does not own or manage the hardware, software, or communications infrastructure. Rather, a command purchases the IT services it requires from a catalog of standard services, and industry will then provide the necessary hardware and infrastructure to deliver those services. Performance requirements for each service are governed by standard Service-Level Agreements (SLAs) to ensure that the command's operational requirements are met.
The NMCI contract was designed to support all basic networking needs of shore users to include：
Network access：
1.   NIPRNET
2.   SIPRNET
3.   Fleet NOC/USN ships
4.    Internet (via NIPRNET)
5.   Ships via piers
6.   Legacy USN networks (Non-NMCI standard).
End-user services：
1.  Standard office suites
2.   Web hosting and browsing
3.   E-mail.
Key concepts that contribute to the full operational capabilities of NMCI include：
1.  Standardizing DON (Navy and Marine Corps) polices, architectures, and products.
2.  Providing basic protection across the DON via the Regional Network Operations Centers (RNOCs) to include piers, bases, commands, posts, and stations.
3.  Maximizing use of commercial off-the-shelf (COTS) internet technology security components (i.e., firewalls, intrusion detection, virtual private network (VPN), virus scanning, etc.).
4.  Hardening infrastructure and diverse connections (i.e., protect against denial of service and/or respond to existing vulnerabilities).
NMCI physical infrastructure consists of numerous LANs connected by base area networks (BANs) for each base or region. Base and regional server and data farms with associated support staffs provide data services. The BANs are connected by two separate WANs to form the Navy enterprise network. Network management and monitoring is provided by four NOCs located at Norfolk, VA； San Diego, CA； Pearl Harbor, HI, and Quantico, VA.
NMCI is designed to provide end-to-end communications within the Navy, seamlessly integrating with afloat naval forces.
2.6.11         OVERSEAS NAVY ENTERPRISE NETWORK (ONENET)
Commands in each region operate and maintain their own IT infrastructure. The Navy is presently extending its enterprise network OCONUS under the ONE-Net modernization program at 16 major fleet concentration areas：
1.  Europe — Naples, London, Rota, Souda Bay, Sigonella, and La Maddalena.
2.  Pacific Far East — Yokosuka, Sasebo, Misawa, Atsugi, Okinawa, Korea, Guam, Singapore, and Diego Garcia.
3.  Middle East — Bahrain.
ONE-Net is intended to replace legacy Navy IT networks and will serve an OCONUS population of 26,000 users. ONE-Net will implement a gigabit Ethernet backbone network on Navy and Marine Corps bases located OCONUS. The ONE-Net architecture is modeled
after the NMCI design in order to insure compatibility and connects to NMCI and afloat networks via the DISN.
In addition to shore networks, ONE-Net has installed network connectivity at CONUS and OCONUS piers at Pearl Harbor, Japan, and Guam. There are validated additional requirements for OCONUS pier side connectivity at Italy, Spain, and Greece.
Operation of ONE-Nets is envisioned to be taken over by NMCI； however, host-nation agreement (HNA) and status-of-forces agreement (SOFA) issues need to be resolved beforehand. Therefore, the Navy Network OCONUS will continue to operate as a Government- Owned/Government-Operated (GOGO) network until transition to a Contractor-Owned/Contractor-Operated (COCO) environment occurs under NMCI.
2.6.12       CONSOLIDATED AFLOAT NETWORKS AND ENTERPRISE SERVICES (CANES)
BACKGROUND：
Over the last two decades, the explosion of networking capability has created unintended consequences aboard afloat platforms. For each type of network requirement the navy identified (e.g., tactical, administrative, classified, coalition, etc.), a separate, distinct network was developed and installed. As a result, the navy's program office for Networks, Information Assurance and Enterprise Services manages a portfolio of multiple, unique networks with various classification levels, operating systems, and protocols. These individual networks are difficult to certify and defend from attacks； they bring their own racks and servers； and they are unable to share server and storage resources. As a result, the space, weight and power required have reached capacity on many platforms.
In order to address these challenges, the program office developed a phased plan to migrate its primary network programs into a single overarching program called Consolidated Afloat Networks and Enterprise Services (CANES). CANES will have at its roots primarily the Integrated Shipboard Network System (ISNS), but will also incorporate the capabilities of other networks such as Combined Enterprise Regional Information Exchange System (CENTRIXS)； the Sensitive Compartmented Intelligence Local Area Network (SCI-LAN)； and the Submarine LAN.
The basic concept of CANES is to take hardware requirements and create a single consolidated computing environment using standard network infrastructure and a common rack architecture. Enterprise services will support hosting of both warfighting and administrative application programs. This evolution requires detailed technical exchanges between the programs' engineers and a significant amount of resource reprogramming.
CANES is a CNO-directed approach to reduce infrastructure and
provide increased capability across the afloat enclaves. It provides technical and programmatic realignment of afloat infrastructure and services, utilizing Open Architectures. CANES will replace ISNS.
CAPABILITIES：
Voice Services
a.   IP Telephony
b.  Mobile and Stationary
c.  Secure and Un-Secure Video Services
a.   Video Teleconferencing
b.   Video/Graphics Distribution Data Services
a.   Network Support
b.    Information Management
c.   Core Infrastructure Services
d.   Network Access (IPv4/IPv6 Capable)
e.   Information Delivery Systems Management
a.   Performance, Availability, & Service Level Mgmt
b.    Fault, Problem, Incident, & Service Desk Mgmt
c.   Configuration, Change, & Release Mgmt
d.   Security Mgmt, IA, CND
e.   Capacity Mgmt

CANES GLOBAL INFORMATION GRID - BANDWIDTH EXPANSION (GIG-BE)

The Global Information Grid (GIG) bandwidth Expansion (GIG-BE) is key to realizing the Department's enterprise information environment. It is providing a worldwide, ground-based fiber­optic network that will expand Internet-Protocol (IP)-based connectivity and at the same time effectively and efficiently accommodate older, legacy command, control and communications (C3) systems. This enables an exponential leap in ground-based voice, video and data exchange capabilities for the Department of Defense and the intelligence community.
GIG-BE created a ubiquitous “bandwidth-available” environment to improve national security intelligence, surveillance and reconnaissance, and command and control information sharing. To implement GIG-BE, DISA is aggressively enhanced the existing end- to-end information transport system, the Defense Information System Network (DISN), by significantly expanding bandwidth and physical diversity to selected locations worldwide. The program provides increased bandwidth and diverse physical access to approximately 100 critical sites in the continental United States (CONUS) and in the Pacific and European theaters. These locations are interconnected via an expanded GIG core. Specifically, GIG-BE connects key intelligence, command and operational locations with high bandwidth capability over physically diverse routes, and the vast majority of these locations will be connected by a state-of- the-art optical mesh network design.

2.6.14     HIGH SPEED GLOBAL RING (HSRG)
The AN/USQ-169B(V)1 High Speed Global Ring (HSGR) provides increased capacity and connectivity in the transport communications links between major Naval ashore claimants. The HSGR transforms the legacy AN/USQ-169A(V)1 Automated Digital Multiplexing System (ADMS) shore connectivity architecture into an integrated network of transport services that provides the warfighter with a dynamic, reliable, flexible and restorable transport service capability. The HSGR enables implementation of new and improved capabilities. These include Fleet Network Operation Center (FLTNOC)-to-FLTNOC connectivity and Joint Service Imagery Processing System-Navy Concentrator Architecture (JCA) connectivity.
The primary purpose of the HSGR is to provide an increased transport link between NCTAMS PAC, NCTS San Diego, NCTAMS LANT, NCTS Naples, Italy and NCTS Bahrain. The HSGR network utilizes ATM, which provides transport services for high speed classified and unclassified IP networks as well as existing Legacy to major shore sites. All IT-21 IP traffic bound for another IT-21 resource will remain on Navy controlled networks utilizing the HSGR. The HSGR uses Marconi TNX-1100 and Lucent PSAX 23 00 Asynchronous Transfer Mode (ATM) switches interconnected via DISN ATM services or commercial leased lines to interconnect the two NCTAMS, NCTS San Diego, NCTS Naples, Italy and NCTS Bahrain. The HSGR is depicted in Figure 2-10 and 2-11.

Figure 2-11 High Speed Global Ring mesh topology
1  HSGR ADVANTAGES
backbone enables reconfigurable class and Quality of (QoS) parameters for data transport supporting tactical ATM is a dedicated connection switching technology that es digital data into 53-byte cell units and transmits them physical medium using digital signal technology. ually, a cell is processed asynchronously relative to elated cells and is queued before being multiplexed over nsmission path. ATM transmission rates operate at either 55 Mbps) or OC-12 (655 Mbps), though speeds on ATM s can reach up to OC-192 (10 Gbps). Operationally, the chitecture supports the following critical warfighting ments：
Increased bandwidth capacity between major shore facilities to support the requirements of the warfighter, to include：
a.  Near-real-time access to information and network services.
b.  Support shipboard terminations above 2 Mbps.

2.  Automated Digital Network System (ADNS) Increment (INC) II/III load distribution, to include：
a.  Provide primary path for Unclassified (UNCLAS) traffic with Commercial Wideband Satellite Program (CWSP) capable ships terminated in NCTS Naples, Italy or NCTS Bahrain.
b.  Provide failover path for all classes of traffic over CWSP when Defense Satellite Communications System (DSCS) is unavailable.
c.  Provide failover path for JCA traffic when CWSP path is unavailable.
3.  Provide for FLTNOC-to-FLTNOC (N2N) and other inter­theater network services restoral.
4.  Super High Frequency (SHF) connectivity restoral.
5.  Consolidation of other program of record terrestrial leases, to include transition of existing ADMS trunks across the HSGR backbone.
6.  Interface with Department of Defense (DoD)
Transformational programs (e.g. DoD Telecommunications Portal (TELEPORT), Global Information Grid (GIG)- Bandwidth Expansion (BE) and Transformational Communications Architecture [TCA]).
The ADNS to HSGR interface bandwidth is currently rated at OC-3 (155 Mbps) with future growth to OC-12 (655 Mbps). However, the current provision for ADNS traffic across the ring is 18 Mbps.
The HSGR as the Navy shore ground transport architecture creates an infrastructure to provide new Fleet services, improve performance and reliability for Fleet services and creates a flexible infrastructure that scales for the consolidation or expansion of FLTNOC services. Additionally, it also provides the infrastructure to deploy enterprise collaboration tools and applications that were previously blocked by the Fleet boundary firewalls.
2.6.14.2     HSGR NETWORK MANAGEMENT
Network Management refers to the broad subject of managing computer networks, using a variety of tools, applications and devices. HSGR Network Management is accomplished through：
1.  Direct connect (console)
2.  Remote (IP, SNMP)
3.  Distributed Local Area Network (LAN) Emulation (DLE)
The following tools are used in support of network management of the HSGR：
Service On Data (SOD) is a Marconi product that was implemented to provide management capabilities for the HSGR

 

core ATM switches.
2.  Lucent AQueView is a Simple (SNMP) based software suite capabilities for the Lucent
3.  Solarwinds software package
2.6.15                  N2N - NOC TO NOC
Network Management Protocol that provides management PSAX edge ATM switches. to analyze bandwidth throughput.

 

There are four IT-21 FLTNOCs geographically dispersed around the world to service deployed users. Each IT-21 FLTNOC is typically responsible for providing services to Fleet users located in their corresponding AOR. The four independent FLTNOCs have their own separate connectivity centers and do not exchange data directly with other FLTNOCs. The IT-21 FLTNOCs are located at the following locations：
1.  European Central Region (ECRNOC)- NCTS Naples, Naples, Italy
2.  Indian Ocean Region (IORNOC)- NCTS Bahrain, Manama, Bahrain
3.  Pacific Region (PRNOC)- NCTAMS PAC, Wahiawa, Hawaii
4.  Unified Atlantic Region (UARNOC)- NCTAMS LANT, Norfolk, Virginia
As the Navy migrates towards a two Regional Network Operations and Security Center (RNOSC) and one Global Network Operations and Security Center (GNOSC), the evolution of IP services will become more simplified. The IT-21 FLTNOCs provide a number of critical Internet Protocol (IP) services to the deployed Fleet in each of their respective Areas of Responsibility (AORs). This is accomplished through the use of a flexible network architecture that can meet unique needs of the different regional forces.
These FLTNOCs were originally established as independent data communications systems that only serviced units within specific coverage areas.
N2N leverages the connectivity and capabilities of the High Speed Global Ring as a transport. Access points to the HSGR terminate within each FLTNOC, allowing the ability to route Internet Protocol (IP) data to each other without having to traverse through Defense Information Systems Network (DISN), and subsequently, the destination FLTNOCs Boundary 1 (DISN facing) firewall architecture. Figure 2-12 provides an overview of the HSGR and its entry points into each FLTNOC：

The upshot of implementing N2N is FLTNOC interconnectivity and restoral capability should a FLTNOC lose connectivity on their DISN path. If a FLTNOC is unable to utilize their DISN connection, their outbound network traffic will automatically be diverted across the HSGR to another FLTNOC to utilize their DISN path.
The establishment of N2N allows the following capabilities that were previously unavailable：
1.  Transform four independently operated FLTNOCs into a single unified IT-21 FLTNOC Enterprise, providing transparent redundant services and security to the Fleet.
2.  Provides the infrastructure to deploy Enterprise collaboration tools and applications that were previously blocked by the Fleet Boundary 1 firewall.
3.  Enhanced security by keeping Fleet traffic on Navy controlled networks.
4.  Enhanced security by providing an Enterprise wide view of security management and monitoring devices.
5.   Improved ability to withstand denial-of-service attacks.
6.  Enhanced network monitoring by providing an Enterprise view of all IT-21 FLTNOC circuits, servers, and equipment.
7.  Improve configuration management by providing the infrastructure for a central repository for system configurations (server/router/switch configurations).
8.  Eventually, with the exception of embarked units (e.g. CVW or CCSG), the need for IT-21 FLTNOC system configuration changes when ships move between AORs will be eliminated.
9.  Provide continuity of service for the Fleet in the event of IT-21 FLTNOC outages.
2.6.15.1     N2N REMOTE RESTORATION
The N2N Enterprise Network provides the framework for connectivity to a central repository, which maintains configuration management and off-site backups of FLTNOC assets.
A FLTNOC can retrieve device configurations from the central repository if necessary.
2.6.15.2     N2N SECURITY
Security in the N2N Enterprise Network architecture is addressed on multiple levels to include global policies, procedures and configuration management, and, inter and intra-IT-21 FLTNOC network device security. The routing architecture will be authenticated and encrypted where applicable which reduces the possibility of a false route being injected into the N2N architecture. At each physical ingress and egress of the HSGR's ATM interface will be an Edge suite that consists of a firewall, Intrusion Protection System (IPS) and Edge Router.
2.6.15.3     FAILURE OF THE DISN SERVICE AT THE IT-21 FLTNOC (FAILOVER)
In the event of a DISN failure, or major service outage, all services will be redirected to the failed IT-21 FLTNOC Fleet Router, through the HSGR, to the backup IT-21 FLTNOC Fleet Router. As an example, UAR IT-21 FLTNOC ships will appear as if
they are a PR IT-21 FLTNOC ship and will continue to receive all

via the PR IT-21 FLTNOC. The failover process is
to the Fleet customers and the users.

 

Figure 2-13 shows an example of a DISN failure at UARNOC.

IP Traffic Flow
IT-21 over HSGR
External over NMCI/DISN
Re-routed UARNOC IP Traffic >r----------------------
Figure 2-13 DISN failure at UARNOC

2.6.16             CLASSIFIED TRUSTED NETWORK PROTECTION POLICY (CTNPP)
/ UNCLASSIFIED TRUSTED NETWORK PROTECTION POLICY (UTNPP)
The Navy Classified Trusted Network Protection Policy (CTNPP) and the Unclassified Trusted Network Protection Policy (UTNPP) provide Navy enclave protection to reflect a defense-in-depth measure and the minimum standards for interconnection between Navy trusted networks (networks which comply with UTNPP/CTNPP) and untrusted networks. NTD 09-07 refers.
2.6.17         IP VERSION (IPV6)
Internet Protocol Version 6 (IPv6) is the next generation network layer protocol of the Internet as well as the GIG, including networks such as NIPRNET, SIPRNET, JWICS, and emerging DoD space and tactical communications systems. Implementation of IPv6 is necessary due to the fundamental limitations of the current Internet Protocol, Version 4 (IPv4) protocol, including a maximum of only 4,294,967,296 possible IP addresses (of which, almost 300 million are reserved for special purposes). An IP address is a unique address that computers, routers and switches use to communicate on a network. In its present form, IPv4 cannot support the long-term requirements of both the DoD and the commercial community. IPv6 overcomes these limitations by expanding the available IP address space to accommodate the worldwide explosion in Internet usage. This improves end-to-end security, facilitates mobile communications, provides new enhancements to Quality of Service (QoS), and eases management system burdens. Additionally, IPv6 is designed to run well on most modern high-speed networks (e.g. Gigabit Ethernet, OC-12, ATM, etc.) without experiencing significant decreases on low bandwidth systems. IPv6 also greatly expands the number of available unique IP addresses available for use and eliminates the need for complex address conservation methods such as Classless Inter-domain Routing (CIDR).
2.6.18         GLOBAL COMMAND AND CONTROL SYSTEM - MARITIME (GCCS-M)
GCCS-M is the maritime implementation of the joint services GCCS providing a single, integrated, scalable C4I system. The system supplies information that aids Navy commanders in a full range of tactical decisions. In functional terms, GCCS-M fuses, correlates, filters, and maintains raw data and displays image-building information as a tactical picture. Specifically, the system displays the location of air, sea, and land units anywhere in the world and identifies whether those units represent friendly, neutral, or enemy forces. It operates in NRT and constantly updates unit positions and other SA data. GCCS-M also records the data in appropriate databases and maintains a history of the changes to those records. The user can then use the data individually or in concert with other data to construct relevant tactical pictures, using maps, charts, map overlays, topography, oceanographic, meteorological, imagery, and all-source intelligence information all coordinated into what is known as a CTP that can be shared. Supplied with this information, Navy commanders can review and evaluate the general tactical situation, determine and plan actions and operations, direct forces, synchronize tactical operations, and integrate force maneuver with firepower. The system operates in a variety of environments and supports joint, coalition, and allied forces.
The GCCS-M architecture is composed of three variants： GCCS-M afloat, GCCS-M ashore, and GCCS-M tactical/mobile that includes TSCs, mobile operations control center (MOCC), and Joint Mobile Ashore Support Terminal (JMAST).
2.7 VOICE AND VIDEO SERVICES
2.7.1   VOICE OVER IP (VOIP)
The mission of the Satellite Management Branch (Standardized Tactical Entry Point) and the Teleport Program Office (TPO), and Readiness Contingency and Exercise Support Branch is to extend Defense Information System Network (DISN) services to Joint Forces worldwide using both terrestrial and satellite communications (SATCOM). DISA's goal is to put a net-centric Internet Protocol (IP) architecture in place to better support the Warfighter. An individual DoD Gateway site is intended to be the interface between the deployed users and the Defense Information Systems Networks (DISN). IP based solutions are intended to enhance the DoD Gateways capabilities not replace legacy DISN services. To meet today's IP based solution shift, initial IP based solution suites have been installed at Landstuhl, Germany, Camp Roberts, California, and Fort Monmouth, New Jersey. The IP based solution suite supports SIPRNET (Secret Internet Protocol Router Network, NIPRNET (Unclassified but Sensitive Internet Protocol Router Network), Voice over IP (VoIP), JWICS, DRSN, Commercial ISP, and Commercial Voice applications. These emerging IP based solution exploit both traditional FDMA SATCOM modems and IP SATCOM Modems (current force and Joint Internet Protocol Modem (JIPM)) for long haul transport. The individual requirements are numbered to aid in tracking and for cross-referencing between the segment specifications, the system specification, and the Teleport Operational Requirements Document. The numbering system uses a designator in the following format： BXXXX, in which B is a letter defining the system or segment and the Xs represent numerals. The current conceptual the Teleport IP based solution equipment is annotated. The design incorporates three main new elements into the existing baseband architecture and new equipment to the encryption element： a convergence element (also known as the convergence router), a VoIP functionality (also known as the VoIP
gateway), a performance enhancing proxy (PEP) element, and a High Assurance Internet Protocol Encryption (HAIPE). HAIPE devices provide traffic separation and COMSEC functionality.
The convergence router will bring together NIPRNET, SIPRNET, and DSN VoIP traffic into a packet stream. The aggregate of the convergence router can be sent to either to the Multiplex Integration and Digital Communications Satellite Subsystem Automation System (MIDAS) or the IP SATCOM Modem. MIDAS will then transmit the Convergence Router traffic to the STEP/Teleport System's transmission security (TRANSEC) element. From the TRANSEC element, the MIDAS connects to the FDMA modem for transmission via satellite. The IP SATCOM Modem will support IP over Transponded SATCOM as well. The TRANSEC solution for IP SATCOM Modem employment is still not defined. The deployed warfighters' suite of equipment will reverse the convergence process, using similar equipment, by means of interoperable routing protocols and encryption keys for TRANSEC and communications security (COMSEC). The Encryption Element provides the TRANSEC and COMSEC required by the Gateway Systems. All satellite transmissions require TRANSEC in accordance with CJCSI 6510.01D, Information Assurance (IA) and Computer Network Defense (CND). COMSEC will be applied to all tactical circuits requiring COMSEC. The DoD Gateway System does not support unencrypted data above the Secret level； for example, JWICS and DRSN data passes through the systems encrypted. The interconnection element provides the electrical and physical interface between most elements of the DoD Gateway. It supports connectivity to either serial interface from the convergence router to the encryption element for TRANSEC or Ethernet connection into a IP SATCOM Modem. The modem element provides both FDMA modems and IP SATCOM Modems (TDMA) interfacing with the DoD Gateway terminal equipment for transmission over the satellite to the warfighter. The modems provide the needed modulation and demodulation for the SATCOM link. The VoIP gateway will be used to interface with the DSN and to convert legacy DSN voice to VoIP. The VoIP traffic will be sent to the convergence router to be merged with the NIPRNET and SIPRNET traffic.
B1190—The VoIP gateway shall support IPv4.
B12 00—The VoIP gateway shall support IPv6 or have a migration plan to implement IPv6 in future releases.
B1210—The VoIP gateway shall support QoS and CoS. All DoD Gateways will adhere to defined DISN CORE CoS and QoS standards and policies.
B1220—If no DoD policy with respect to QoS and CoS has been established, the VoIP gateway QoS and CoS shall comply with tactical user configurations.
2.7.2     DOD VIDEO TELECONFERENCING SERVICE (VTC)
VTC is an extension of traditional telephony technologies with the added feature of being able to see the person or persons with

whom one is talking. Another way to consider VTC technology is an extension or combination of television, which provides the audio and video communication aspect, and telephony or
telecommunications which provides the addressable, bi-directional connectivity. The results of which are a bi-directional, “closed circuit”, dial-able, TV system. The television portion of the technology uses video display screens (televisions/video monitors/projectors), video cameras, microphones, and speakers at each location connected to a Coder-Decoder (CODEC). The CODEC is the interface between the analog voice/video devices in the system and the addressable connectivity or transmission portion of the system. The CODEC converts the analog signals to digital format that is compatible with the transmission media. The CODEC also interfaces and converts presentation and whiteboard information. The combined digital signal is then transmitted to the remote location via a telecommunications network which is either TDM or IP based. Quality VTC communications requires much higher bandwidth than voice or traditional data communications. The actual bandwidth required is dependent upon the CODEC and compression algorithm used. The typical minimum bandwidth requires is 128Kbps with 384Kbps being typical and required for quality video. Some CODECs require as much as 2Mbps in support of high definition video.
The telecommunications network used for VTC connectivity is a traditional circuit switched telephony network such as the Defense Switched Network (DSN) and/or Public Switched Telephone Network (PSTN). The DSN is the preferred network for DoD VTC connectivity. Both of these networks are based in TDM technologies and typically provide Integrated Services Digital Network (ISDN) lines for access to the network. Both Basic Rate interface (BRI) and Primary Rate interface (PRI) ISDN lines are used. Addressability is handled as with any other telephone instrument, the address is the phone number associated with the line from the circuit switch to the instrument.
.3 DEFENSE SWITCHED NETWORK (DSN)
The Defense Information System Network (DISN) provides global voice services through the Defense Switched Network (DSN), a worldwide private-line telephone network. Multilevel precedence and preemption (MLPP) capabilities on the DSN utilized by command and control users ensure that the highest-priority calls achieve connection quickly, especially during a crisis situation. The DSN also provides global data and video services using dial-up switched 56Kbps or 64Kbps Integrated Services Digital Network (ISDN) services. Secure voice services are provided by the Secure Telephone Unit, Third Generation/Secure Terminal Equipment (STUIII/STE) family of equipment that provides end-to-end encryption over non-secure DSN circuits. Interfaces are provided between strategic and tactical forces, allied military and Enhanced Mobile Satellite Services (EMSS).
DEFENSE RED SWITCH NETWORK (DRSN)
The Defense Information System Network (DISN) provides global secure voice services using the Joint Staff Defense Red Switch Network (DRSN). The Joint Staff grants approval to access the network. The mission of the DRSN is to provide the President, Secretary of Defense, National Command Authority (NCA), the National Military Command Center (NMCC), Combatant Command Centers, Warfighters, and other critical Department of Defense and federal government agencies with reliable, secure, interoperable C2 and crisis management capabilities.
2.7.5     INTEGRATED SERVICES DIGITAL NETWORK (ISDN)
ISDN is a circuit-switched telephone network system, designed to allow digital transmission of voice and data over ordinary telephone copper wires, resulting in better quality and higher data speeds than are available with analog. More broadly, ISDN is a set of protocols for establishing and breaking circuit switched connections and for advanced call features for the user.
2.7.6     PLAIN OLD TELEPHONE SYSTEM (POTS)
POTS refers to an un-enhanced telephone service with the ability to send and receive phone calls. In POTS, once a dedicated circuit connects the call, your voice is transmitted by a 4kHz analog wave form via a process known as a frequency division multiplexing. 4kHz band is used because it provides enough bandwidth to reproduce a recognizable human voice. Further, each channel supports a range of single amplitude (strength) that relates to a volume level. The amplitude level is limited, so no matter how loud you scream over the network it won't exceed a certain volume on the other end of the line. Together this combination of bandwidth and amplitude is not quite enough for perfect voice transmission, but is good enough so you can make out the words and recognize familiar voices.
.7 AFLOAT PERSONAL TELECOMMUNICATIONS SYSTEMS (APTS)
Providing personal telecommunications service to shipboard crewmembers at sea is a highly visible quality of life issue that positively affects the life of the sailor at sea. To maintain clear separation of appropriated and non-appropriated activities, SPAWAR and Navy Exchange Command (NEXCOM) work collaboratively to insure that the definition of technical and procedural requirements do not conflict in planning for future commercial services. This clear separation of functionality and funding is
known as the APTS system. With a fully complemented CV/CVN, costs per minute have driven down phone call charges into the $1.00 per minute range. A commercial smart debit card now provides telephone services for personnel on most ships equipped with the APTS “Sailor Phones".
2.7.8     KY68 DIGITAL SUBSCRIBER VOICE TERMINAL (FDVT)
KY68 is a ruggedized field terminal containing the audio processing, signaling and Communications Security (COMSEC) functions necessary to provide secure and non-secure voice and secure data access to circuit switched digital networks, and to provide secure access to a variety of non-switched, point-to- point (sole user) digital networks. The TSEC/KY-68 DSVT digitizes voice information using Continuously Variable Slope Delta (CVSD) modulation at a 16 or 32Kbps rate. The KY-7 8 is the strategic version.
2.7.9     VIDEO INFORMATION EXCHANGE SYSTEM (VIXS)
The video information exchange system (VIXS) provides a secure, GENSER SECRET and SCI, multipoint, interactive video teleconference (VTC) capability that facilitates efficient communications among CNO, fleet commanders, commanders at sea, Navy and Marine Corps fleet command authorities, and other users. It was originated in 1992 as CNO VTC and expanded to the fleet flagships in 1993. In 1994 the name was changed to VIXS and it expanded to include CVs, CVNs, and large deck amphibious ships, LHAs and LHDs. VIXS was implemented with COTS VTC systems and multipoint control units (MCUs) (bridging units) and utilizes Navy-standard cryptographic equipment. This integrated system supports global tactical C2 requirements to conduct distributed, collaborative planning.
Through the use of compressed digital transmission, the system provides a cost-effective means of producing high-quality video images using reduced bandwidth. VIXS conferences are normally held at 128-256Kbps. This reduced bandwidth requirement minimizes the expense of long distance service to Europe and allows SATCOM connectivity to Navy ships at sea. Normal shipboard bandwidth is 12 8 kbps, but CWSP gives equipped ships the bandwidth required to conference at 256 or 384Kbps. Live motion video, camera auto queue on speaker, computer graphics, videotape, document images, white boarding, and file sharing can currently be transmitted over the system. Support can be provided for up to 16 conferencing sites, enabling 8 simultaneous point-to-point conferences, or a series of mixed point-to-point and multipoint conferences. Gateways located at MCU sites provide access to other networks.
VIXS hubs are located at：
1.   NCTAMS LANT Norfolk, VA
2.   NCTS NAPLES, ITALY Naples, Italy
3.   NCTAMS PAC Makalapa, HI
4.   NCTS Bahrain.
VIXS shore access is provided to COMPACFLT, USPACOM, CFFC, United States Joint Forces Command (USJFCOM), COMUSNAVEUR London and Naples, NAVCENT Bahrain, and CNO. An additional 30 plus sites have been certified as VIXS network users via ISDN dial-up. A support hub at Space and Naval Warfare (SPAWAR) Systems Center (SSC) Charleston provides testing and diagnostics support in addition to providing backup multipoint conference support.
The VIXS shipboard configuration consists of one suite of VTC hardware and two separate encryption paths. One path is classified (GENSER) and the other is JWICS SCI. Both paths are encrypted via a KG-194 or KG-194A.
In FY02, upgrades included incorporation of a second MCU at VIXS hub sites to support simultaneous local unclassified and/or NATO multipoint conferences. Future hub upgrade requirements will include support of IP based systems such as adding an H.323 MCU and H.320/H.323 Gateway to accommodate NMCI user sites as well as adding additional port capacity to the Madge and Montage units to accommodate additional afloat and ashore VIXS users. Additional afloat platforms are expected to include CG and DDG utilizing SHF.
2.7.10       DISN VIDEO SERVICE GLOBAL (DVSG)
DVS-G capabilities include global connectivity, 24/7 availability, multiple security levels (Unclassified, U.S. Secret, and TS), and VTC services via STEP sites. VTC services are provided using multiple configurations (point-to-point, multi-point, switched, or dedicated), speed matching, and bridging services. If C2 capabilities are required, DVS-G must be configured to meet C2 performance measures.
DISA is planning to transition DVS-G to DVS II, a new IP-based network that includes C2 VTC operations. DISA is developing the follow-on DVS II contract； however, implementation dates are not presently available. The follow-on contract requirements include many new technologies, the merging of existing networks, and advanced connectivity to the warfighter. DVS II will build on the DVS-G platform.
The DISN Video Services (VS) provides global DOD VTC users a bridging service using industry standard technology for interoperability and multi-point VTC requirements for both classified and unclassified users. Increased flexibility was added to the system by providing subscribers a way to access VTC users on tactical networks such as the DSCS and DSN, as well as non-DOD networks. Through a cascade of Multipoint Control Units (MCU), DISN VS allows subscribers to access customer MCUs such as the Navy's tactical Video Information Exchange System (VIXS).