Attachment 2 SRD_JOBYFG FOWAN-DWDM_10Mar2025 FINAL v1-0.pdf

CUI

System Requirements Document for

Royal Jordanian Air Force Fiber Optic Wide Area Network Transmission Node Upgrades

10 March 2025 Version 1.0

Prepared by United States Army Communications-Electronics Command (CECOM)

Security Assistance Management Directorate (SAMD) Aberdeen Proving Grounds, Maryland

Controlled by: Communications-Electronics Command Controlled by: Security Assistance Management Directorate CUI Category(ies): OPSEC, CRIT Limited Dissemination Control: REL TO USA, JOR POC: Lisa Marino, 520-671-1739

SYSTEM REQUIREMENTS DOCUMENT

v1.0

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

Hashemite Kingdom of Jordan.

Table of Contents

1. SCOPE

1.1. BACKGROUND

1.2. RJAF VISION

1.3. APPLICABILITY

2. APPLICABLE DOCUMENTS

2.1. MILITARY STANDARDS

2.2. COMMERCIAL STANDARDS

2.3. OTHER DOD DOCUMENTS

3. REQUIREMENTS

3.1. GENERAL ARCHITECTURE

3.2. PHOTONIC LAYER (TRANSPORT) AND OTN REQUIREMENTS

3.3. TRAFFIC SUPPORT AND SERVICES

3.4. PLATFORM DAUGHTER EQUIPMENT REQUIREMENTS

3.5. ENCRYPTION

3.6. NETWORK MANAGEMENT SYSTEM (NMS)

3.7. AVAILABILITY AND RELIABILITY

4. DESIGN BASELINE – PHASE ONE

4.1. RJAF REQUESTED SCENARIO

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

1. SCOPE

The United States Army Communications-Electronics Command (USCECOM) Security Assistance Management Directorate (SAMD) has been tasked to assist the Hashemite Kingdom of Jordan’s Armed Forces (JAF) and the Royal Jordanian Air Force (RJAF) in implementing a new solution to maximize the efficiency of the RJAF Fiber Optic Wide Area Network (FOWAN) node network and increase the flexibility, scalability, availability, and remote configurability of the network to lower operational expenses, turn up new services and enhance the network as needed. This goal will be achieved through phased transmission node upgrades applying design best practices and integrating the latest technologies into the existing capability already in-country. The scope consists of delivering equipment, services, spare parts and training. This System Requirements Document (SRD) forms a part of the requirements authorized under Foreign Military Sales (FMS) Letter of Authorization (LOA) JO-B-YFG.

The Contractor shall provide materials, services, and training under a single Firm-Fixed Price (FFP) contract. The word Government in this document refers to the United States Government (USG). The words End User in this document refers to the JAF and/or RJAF.

1.1. BACKGROUND

U.S. Army Communications-Electronics Command (USCECOM) is responsible for developing and applying emerging technology to significantly advance the Soldier’s fighting capabilities now and in the future. USCECOM develops and integrates the critical technologies required to provide a speedy transition from research labs to the field, ensuring the long-term superiority of the U.S. Army and our Host Nation partners in the areas of communications, integrated logistics support, border security, information warfare and intelligence systems.

With the growing demand for various services and bandwidth on RJAF FOWAN nodes and simultaneous decrease in capital budgets, the onus is now on RJAF to use their existing fiber optic networks to satisfy the current and future military needs especially the high bandwidth services for the security agencies and other departments. RJAF is currently having Synchronous Transport Module, level 16 (STM-16) optical lines with few STM-64 optical lines, therefore, RJAF is looking to install a new transmission node (platform) that meets the expansion needs by providing protection and performance monitoring while supporting a flexible and transparent mix of traffic protocols including Internet Protocol (IP), Fiber Channel, Ethernet, synchronous digital hierarchy (SDH).... etc.

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

1.2. RJAF VISION

RJAF is looking forward to implement a new solution that maximize their network’s efficiency (deliver more with less) and increase the flexibility, scalability, availability and remote configurability of a network to lower operational expenses and can turn up new services and alter network as needed. The implementation of this solution is planned in phases to deliver new nodes (platform) with the latest technologies such (OTN, Coherent DWDM) or any recommended solution that complies with the general requirements, specification and services shown at (3. Requirements) for high flexibility, interoperability, scalability and future expansions and upgrades taking into account that the whole RJAF FOWAN is a complex network (combination of ring and mesh topologies).

The key objectives for the FOWAN upgrades include:

A. Long-term reduction to operational and capital expenditures.

B. Increased bandwidth/capacity and rapid provisioning.

C. Topology flexibility and simplified operation.

D. Optimal utilization of fiber optic cabling.

E. Achieving the lowest latency and jitter for delay-sensitive traffic according to ITU-T standards.

F. RJAF organic sustainment and maintenance capability.

G. High availability network management cluster.

The system-level requirements are intended to apply to current and future FOWAN upgrades. The requested scenario (4. Design Baseline) specified below is designated (phase 1) and includes twenty-five (25) sites in the eastern region.

Technical details including fiber specifications, fiber tests, client matrix, upgraded sites and communications standards are all shown in the annexes.

1.3. APPLICABILITY

This effort is within the scope and adherence to the basic contract.

2. APPLICABLE DOCUMENTS

2.1. MILITARY STANDARDS

Reserved.

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

2.2. COMMERCIAL STANDARDS

Reserved

2.3. OTHER DOD DOCUMENTS

Annex A Fiber Tests Using FLS and FPM Test Set Annex B OTDR Test Equipment Annex C Client Interfaces – General Traffic and Details Annex D Upgrading RJAF Transmission Nodes (JBSP) Annex E Standards to be Supported Annex F Acronyms

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

3. REQUIREMENTS

3.1. GENERAL ARCHITECTURE

3.1.1. The new transmission node platform, also referred to as simply platform, shall be modular (i.e. slot-based chassis).

3.1.2. The platform shall use Ciena products.

3.1.3. The platform shall be able to perform Dense Wavelength-Division

Multiplexing (DWDM) muxponder, packet switching, Optical Transport Network (OTN) switching, line amplification, Multiprotocol Label Switching (MPLS) and Reconfigurable Optical Add-Drop Multiplexer (ROADM) functions all in the same shelf.

3.1.4. The platform shall be available in various shelf sizes, all of which use the same software load.

3.1.5. The platform chassis shall have universal slots to house all possible units needed to build the various DWDM system configurations like transponders, muxponders, amplifiers and ROADMs.

3.1.6. The proposed nodes (platform) shall support various topologies including:

a) Point to Point.

b) Linear add drop topology.

c) Mesh Network System.

3.1.7. The platform shall be managed by the same NMS system for all variants across different layer (L0, L1, L2).

3.1.8. The platform shall support Shelf Processor (SP) redundancy.

3.1.9. The platform shall support fan and power card redundancy.

3.1.10. The platform shall be able to be installed in any one of European

Telecommunications Standards Institute (ETSI) (535mm), 19 inches, and 23-inch racks.

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

3.1.11. The node (platform) shall be equipped with fully redundant power supply modules and shall work on -48V DC power supply. The node (platform) shall be protected in case of voltage variation beyond the range specified and also against reverse input polarity. The derived DC voltages in the equipment shall have protection against over-voltage, short circuit and overload. The equipment shall have the option of operating from two independent sources of input power supply.

3.1.12. The platform shall support both passive filter as well as ROADM-based connectivity options.

3.1.13. The platform shall have an interface for connecting Local Craft Terminal (LCT) for supervise this platform (network element).

3.1.14. At any given point in time, it shall be possible to identify the traffic flows of each individual application/service and to optimize the network for packet traffic.

3.1.15. The platform equipment shall be capable of operating in a temperature range from +5 deg Celsius to +40 deg Celsius.

3.2. PHOTONIC LAYER (TRANSPORT) AND OTN REQUIREMENTS

3.2.1. The DWDM equipment shall support long haul regional and metro applications.

3.2.2. The DWDM system shall support a highly modular architecture to accommodate diverse network topologies, such as point to point, linear add-drop and ring configurations, to ensure smooth and flexible network upgrades.

3.2.3. The proposed node (DWDM equipment) shall be in accordance with ITU-

T G.694 and capable of supporting the minimum following functions:

a) Line amplification.

b) Optical channel add/drop module.

c) Optical supervisory channel (OSC) termination.

d) Optical performance monitoring.

e) Optical Channel Monitoring.

f) Optical or wavelength express or bypass.

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

3.2.4. The DWDM equipment shall be equipped with all required physical ports for the add/drop channels.

3.2.5. The DWDM system shall be designed to provide (100/200Gbps) traffic per lambda based on the latest coherent technology (meeting the Polarization Mode Dispersion (PMD) and Chromatic Dispersion (CD) requirements in the existing fiber networks taking into consideration all margins and real assumptions).

3.2.6. The DWDM system shall provide in future (400/600/800 Gbps) traffic per lambda based on the latest coherent technology (meeting the PMD and CD requirements in the existing fiber networks taking into consideration all margins and real assumptions).

3.2.7. The system shall have the capability to perform coherent modulation with software-programmable modulation formats for all supported rates on the muxponders/transponders.

3.2.8. The network shall support a (5-7) dB fiber margin to accommodate and guarantee the operation of the network taking into consideration the optical budget in Annex A that was performed using an optical laser /power test set.

3.2.9. The DWDM system shall support either an integrated (wavelength selective switch (WSS) and amplifier) module to help in reducing the complexity of the solution or a separated (WSS and amplifier) module in order to optimize and enhance the optical performance regarding the fiber cable losses.

3.2.10. The DWDM system shall utilize a flex-Grid ROADM architecture supporting 8-9 photonic degrees per node, employing either conventional or colorless-directionless-contentionless (CDC) ROADM technology for scalability and efficient wavelength management.

3.2.11. The nodes (network) shall be able to support multiple channels add/drops per site (at least 40 channels) using fixed color mux/demux module (filters) or (colorless) assignment per port.

3.2.12. The network shall support a minimum of 40 channels from Day 1.

3.2.13. The system shall be upgradeable to the final capacity without any interruption in traffic and without any change on the photonic HW provided from Day 1.

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

3.2.14. The system shall employ amplification using Erbium-Doped Fiber

Amplifier (EDFA) technology and the Raman amplification as second choice where needed.

3.2.15. The DWDM system amplifiers shall be designed to ensure hitless in-service insertion of new channels or removal of channels.

3.2.16. The DWDM system shall provide optical channel, card and equipment protection mechanisms to ensure the high reliability required by various applications.

3.2.17. The system shall support optical supervisory channel (OSC) that is inserted and extracted at each node. Both ROADM’s and optical amplifiers should be managed through the offered OSC.

3.2.18. The system shall support built in OTDR with the ability to run Optical

Time Domain Reflectometer (OTDR) traces over in-service links.

3.2.19. The required system shall offer tunable wavelength

transponders/muxponder of the carrier frequency optical module on all the working channels under the C Band to interface the required payload.

3.2.20. The offered transponders/muxponders shall support Forward Error

Correction (FEC) and they are preferable to support Soft-Decision Forward Error Correction (SD-FEC).

3.2.21. The transponder, muxponder output power shall be remotely provisionable.

3.2.22. The transponder, muxponder shall support adjusting the output optical power for channel balancing and automatic gain control & adjustment of channel power for optimum wavelength stability.

3.2.23. The platform shall be able to monitor the power of individual wavelengths. When power levels go outside of a pre-determined threshold, an alarm shall be triggered before loss of light occurs and service is affected.

3.2.24. The DWDM system shall support “automatic power equalization, automatic gain control, output power balancing” functions.

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

3.2.25. The DWDM system shall automatically adjust the launched power with specified limits with the addition or removal of wavelengths keeping the total optical power constant.

3.2.26. The node (platform) shall support both muxponder and central fabric-based packet/OTN switching solutions.

3.2.27. The system shall support OTN that can groom sub 2.5G, 10G to 100G or higher rates.

3.2.28. The OTN switching shall be capable to enable ODUks (ODU0=1.25G, ODU1=2.5G, ODU2/2e=10G, ODU3=40G, ODU4=100G) and ODUflex (Nx1.25G) to be switched between interfaces, typically via centralized fabrics.

3.2.29. The platform with the network management system (NMS) shall support

MBB (Make Before Break) capability on L1 OTN services. This ability or capability provides hitless traffic migration which can be used as part of maintenance task that reduce the traffic disruptions (lower impact on end-customer services) and easy service re-grooming for higher network efficiency.

3.2.30. The platform with the network management system (NMS) shall support latency-based routing on L1 OTN services.

3.3. TRAFFIC SUPPORT AND SERVICES

3.3.1. CLIENT INTERFACES

3.3.1.1. The offered platform shall support the following client traffic interface types:

a) Ethernet (FE/GE/10GE/40GE/100GE)

b) SDH (STM-1/STM-4/STM-16/STM-64)

c) SONET (OC-3/OC-12/OC-48/OC-192)

d) OTN (OTU-1/OTU-2/OTU-3/OTU-4, ODUflex)

e) SAN (FC100/FC200/FC400/FC800/FC1200/FICON)

f) Any service at rates ranging from (100 Mbps to 100 Gbps)

3.3.1.2. All provided Client interfaces shall have pluggable inserted in the port according to the type of interfaces. Flexible protection schemes and options for hardware and multi-protocol services can be provided such

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the as (1+1) protection, (N:1) protection and SNCP protections for various scenarios (i.e., client to client, client to line, and line to line).

3.3.2. L2 (PACKET) TRAFFIC SERVICES

3.3.2.1. The platform shall support both module-based as well as central fabric-based Layer 2 switching.

3.3.2.2. The platform shall be able to support Metro Ethernet Forum Carrier Ethernet (MEF CE) 2.0-certified ethernet services such as 10GE and 100GE services and optionally support CE 3.0 certified services.

3.3.2.3. The platform shall support E-LINE, E-LAN, and E-TREE services and meet VLAN tagging according to IEEE 802.1p, IEEE 802.1q and VLAN stacking or (Q in Q) according to IEEE 802.1ad that include VLAN steering and support of all Ether type values (like 0x88A8, 0x8100, 0Xffff) and Class of Services (CoS) and priorities.

3.3.2.4. The platform may support Open Virtual Private Network (O-VPN) services. (Optional)

3.3.2.5. Platform might support extended temperature variant of packet switch module. (Optional)

3.3.2.6. The platform shall support >100G packet switching capacity on its blade-based Ethernet-switch modules.

3.3.2.7. The platform shall support fabric-based packet switching among GE, 10GE, 100GE and 100G DWDM.

3.3.2.8. The platform shall support packet fabric that can also simultaneously support OTN switching without loss in capacity.

3.3.2.9. The platform could support per port flood containment on its packet switch modules to control and protect the network against packet storms. (Optional)

3.3.2.10. The platform shall support G.8032 Ethernet Ring Protection.

3.3.2.11. The platform shall support MPLS-TP.

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

3.3.2.12. The platform shall support Ethernet sub-rating onto ODUFlex containers.

3.3.2.13. The platform shall support Synchronous Ethernet (SyncE).

3.3.2.14. The platform shall support Link Layer Discovery Protocol (LLDP) according to (IEEE 802.1 AB).

3.3.2.15. The platform shall support traffic management such as support IEEE 802.1ag CFM (Connectivity Fault Management) for service monitoring, loopback and link trace,802.3ah Operations, Administration, and Maintenance (OAM) and IEEE Y.1731 Performance Monitoring for delay measurements.

3.3.2.16. The platform shall support Static ARP (Address Resolution Protocol).

3.3.2.17. The platform shall support Link Aggregation (LAG), for the ability to distribute capacity among multiple ports.

3.3.2.18. The platform shall support soft resets without impact to packet traffic.

3.3.2.19. The platform shall support IPv4 and optionally IPV6.

3.3.2.20. The platform should support in-service software upgrades for packet traffic. (Optional)

3.3.2.21. The platform shall be able to map 10G clients or ports to 100G lines or ports.

3.3.2.22. The platform shall operate at the layer 2 (data link layer) - 64 byte to 9600- byte Ethernet frames (jumbo frames support).

3.4. PLATFORM DAUGHTER EQUIPMENT REQUIREMENTS

3.4.1. Platform daughter equipment shall consist of compact, cost-effective high-performance device or devices (i.e. mux) designed for efficient aggregation and service delivery in metro and edge networks, supporting a range of Ethernet speeds and advanced networking features.

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

3.4.2. Platform daughter equipment shall facilitate seamless expansion to accommodate increasing client traffic, ensuring that the platform at each site is utilized to its best potential.

3.4.3. Platform daughter equipment shall function as an integrated traffic card within the platform, enhancing its capabilities and providing an efficient approach to network management and service delivery.

3.4.4. Platform daughter equipment shall have dual -48Vdc power inputs for redundancy, flexibility and minimize downtime.

3.4.5. The platform daughter equipment shall be a compact size (1RU or 2RU) and capable to be installed in any one of ETSI (535mm), 19 inches, and 23-inch racks.

3.4.6. The platform daughter equipment shall be capable of operating in a temperature range from -40 deg Celsius to +65 deg Celsius.

3.4.7. The platform daughter equipment shall support high-capacity, non-blocking switching fabric (higher than 100 Gbps).

3.4.8. The platform daughter equipment shall be designed to handle high-capacity switching applications, with hardware-assisted packet OAM for delivering services with guaranteed SLA differentiation.

3.4.9. The platform daughter equipment shall support multiple Ethernet speeds (interfaces) including (FE,1GbE, and 10GbE) that host the Ethernet client interfaces stipulated in Annex (C).

3.4.10. The platform daughter equipment shall support multiple Ethernet speeds including (10GbE or 100GE) that can be used to groom or aggregate multiple FE, 1GbE or 10GbE respectively.

3.4.11. The platform daughter equipment shall be managed by the NMS.

3.4.12. The platform daughter equipment shall have built-in tools to test how well the network performs. These tools use industry standards such as RFC 2544 and ITU-T Y.1564 to measure things like speed, delays, and lost data, making it easier to check and confirm that the network is working properly.

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

3.4.13. The platform daughter equipment shall at a minimum support the following industry specifications/standards:

a) IEEE 802.1Q VLANS.

b) IEEE 802.1ad Provider Bridging (Q-in-Q).

c) IEEE 802.1p Class of Service (CoS) prioritization.

d) IEEE 802.3 Ethernet standards.

e) IEEE 802.3ad Link Aggregation Control Protocol (LACP).

f) Jumbo Frames: Support up to 9216 bytes.

g) IEEE 802.1ag Connectivity Fault Management (CFM).

h) IEEE 802.3ah EFM Link-fault OAM.

i) ITU-T Y.1731 Performance Monitoring.

j) RFC5654 Requirements of an MPLS Transport Profile (MPLS-TP).

3.4.14. Different platform daughter equipment types should be used to optimize client port utilization and switching capacity by combining and managing Fast Ethernet (FE) and 1GbE/10GbE interfaces. (Optional)

3.5. ENCRYPTION

3.5.1. The platform shall be capable to offer an AES-256 wire-speed encrypted 10G, 100G, and future 200G services; capability is not required Day 1.

3.5.2. The platform shall be capable to offer a FIPS-197 certified AES-256 encryption engine; capability is not required Day 1.

3.5.3. Encryption solution shall be capable to support a TLS-secured and mutually authenticated interface for encryption management; capability is not required Day 1.

3.5.4. Encryption solution shall be capable to offer a dedicated management user interface that provides full control in managing all security parameters; capability is not required Day 1.

3.5.5. The platform shall be capable to offer hitless key rotation, with session key rotation interval in seconds; capability is not required Day 1.

3.5.6. The platform shall be capable to offer separate keys for authentication and encryption functions; capability is not required Day 1.

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

3.5.7. The platform shall be capable to offer 100G/200G encryption on a coherent line card; capability is not required Day 1.

3.5.8. The platform shall be capable to offer a FIPS 140-2 Level 2 certified solution; capability is not required Day 1.

3.5.9. The platform shall be capable to offer the ability to mate this 100G/200G encrypted line card with a wide range of clients to best address customer requirements for various services; capability is not required Day 1.

3.5.10. The platform shall be capable to offer the 100G encrypted waves (or services) across a hybrid packet/OTN switched infrastructure; capability is not required Day 1.

3.5.11. The platform shall be capable to offer the flexibility to support 100G and 200G optical encryption on the same hardware with programmable modulation; capability is not required Day 1.

3.6. NETWORK MANAGEMENT SYSTEM (NMS)

3.6.1. The NMS shall provide automated multi-layer service management, provisioning, assurance, network discovery, inventory, optimization, protection and full Fault, Configuration, Accounting or Administration, Performance, Security (FCAPS) functionality.

3.6.2. The NMS shall be able to support the existing fiber optical network and manage the DWDM systems.

3.6.3. The NMS shall provide a real time, accurate view of the network and services to integrate equipment and network capacity demand planning.

3.6.4. The NMS shall support Multi-layer network path computation engine for service creation and modification.

3.6.5. The NMS shall offer open Representational State Transfer Application

Programming Interfaces (REST APIs) for ease of integration into adjacent systems (Billing and Operations Support Systems (B/OSS) and Orchestration layers)

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

3.6.6. The NMS shall be configured as (1+1) clustering and load balancing for high availability and geographically redundant configurations and scalability and as an option allow for upgrade to (N+1) cluster in future.

3.6.7. The NMS shall manage the OTDR functionality and provides automated scan of fiber plant at turn-up and during faults and identify high losses or reflections in seconds, enabling quick troubleshooting and repair and offers proactive monitoring and maintenance by identifying potential fiber issues, avoiding future outages.

3.6.8. The NMS should offer advanced network and service visualization provided in a single Web-based interface for improved user access and user experience. (Optional)

3.6.9. The NMS shall contain embedded software defined networking (SDN) controller for automation capabilities and improving network management performance and communication with network nodes.

3.6.10. The NMS should support micro-service software architecture that allow the system to be divided into a number of smaller, individual and independent core functions such as communication, database and web-applications, each function is called a micro-services that are put in containers (software packages) which can communicate with each other and can be built and deployed independently so they can operate and fail without negatively affecting the others making the maintenance, troubleshooting and extending of the system easier. (Optional)

3.6.11. A data communication network (DCN) plan shall be provided for the communications between nodes and the NMS system, and if it’s necessary to provide a proper sync plan for these new nodes.

3.6.12. The interoperability with other multi-vendors such as the current Ericsson

Optical Multi-Service (OMS) and Smart Packet Optical (SPO) platform nodes (current RJAF network) shall be considered as client for the new platform (node) allowing creation and activation of services such as E1,E3,STM-1,EOSDH transparently between existing Ericsson nodes through these new transport nodes using the current Ericsson NMS.

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

3.6.13. The NMS shall support NBI (northbound interface) for future 3rd party management interoperability (orchestration), including any required communication protocols such as SNMP.

3.6.14. The NMS system shall have the ability to integrate with ArcGIS for future purposes.

3.7. AVAILABILITY AND RELIABILITY

3.7.1. Protection switching for services based on automatic protection switching based on the chosen Technology. The back-up path will be activated automatically whenever a fault occurs on the active path. The active/backup scenario shall be predefined in the system with the network management system. This shall be done via point and click within the network management systems and shall supersede any dynamic routing protocol to make the protection switching deterministic.

The protection switching shall be bidirectional to avoid differential delay.

3.7.2. In the event a single fiber in a fiber pair is broken both transmit and receive links need to switch over (ALS).

3.7.3. The maximum reconfiguration time, in case of a node failure or cable break, shall not exceed 50 milliseconds for 1:1 protected services.

3.7.4. Configuration data shall be stored locally in every access node to ensure a quick restart after a power outage.

3.7.5. The database holding all relevant information on the system configuration shall be backed up in the network management system. If

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the configuration data is lost in a node, the network management system shall be able to restore the data remotely.

3.7.6. To increase the reliability of the network it shall be possible to spread the links towards other nodes in the network over different interface cards.

This shall allow the replacement of an interface card without disconnecting the node completely from the network.

3.7.7. The network management system shall provide a way to easily create pdf or csv-based reports. Any information stored in the database shall be usable for creating custom reports. A mechanism to create custom reports shall be available, e.g. XML based.

3.7.8. It shall be possible to make following on-line changes: activation or deactivation of interface cards, add or remove interface cards, and add, change, or remove services. Each change shall automatically update the database on NMS.

3.7.9. It should be possible to create various services over the network via wizards. This wizard shall include all necessary steps and service parameters in a user friendly and logical way. Parameters like bandwidth, quality of service, level of protection, delay, route over the network can be configured. In all conditions the operator shall be able to overrule or change the suggested parameters with more appropriate parameters, but the NMS shall guard the settings and warn in case of inconsistency.

3.7.10. Dual hot swappable power supplies with separate power cords/connections are required. The node chassis shall be equipped with two (redundant and load balancing) power supplies. If one power supply in the redundant node chassis fails, the other power supply shall automatically take over.

3.7.11. The OEM or provider shall provide a certificate in writing that the lifetime and production of the nodes (platform) will be fully supported for a period of ten (10) years from DAY-1 of installation and operation at the required sites. This period includes a minimum of five (5) years before the product becomes manufacture discontinued, followed by a period of five (5) years which the support of this deployed node (platform) is still provided which includes repair and return (R&R) of any part of node (equipment) and supported software release. The OEM or the provider should inform RJAF for any new production (newly node/platform) that compatible with

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the the existing node and can be managed by the NMS (software upgrade) and can be purchased with competitive prices.

3.7.12. The platform software shall be fully compatible with the platform hardware during base POP, maintenance periods, and any executed option periods. This applies to current and new software releases.

4. DESIGN BASELINE – PHASE ONE

The following scenario shall be considered a design baseline for the sites shown in Annex D, Figure 1. The twenty-five (25) sites form a portion of the larger RJAF FOWAN. Considerations shall be made for the RJAF required traffic, fiber cable tests with the information about the fiber routes shown in Annex A and Annex B respectively, and on the allocated budgets taking into account an optical margin between 5-7dB shall be added for each link based on the laser source and power meter test set results shown in Annex A.

4.1. RJAF REQUESTED SCENARIO

4.1.1. The use of transport node (platform) and ROADM using (1λ/channel) carrying unencrypted coherent (100G) optical line.

4.1.2. The implementation of OTN and packet platform (combined one) between the new (sites) shown in (Annex D figure (1)) to replace the existing RJAF (Core/Metro) transport nodes with their (STM-16) links.

RJAF requests on this phase to implement (1λ) carrying coherent (100G) traffic through the optical lines between nodes. RJAF shall be able to add/drop this (λ) at each site using conventional ROADMs or new generation (CDC/CDC-F) ROADMs with future capabilities to add new extra required wavelengths (λ) carrying at least coherent (100G) with (add/drop) and express capabilities based on cost-effective, non-restrictive solutions and future requirements. Each (site) shown in (Annex D figure (1)) shall contain proper equipment (node) with two-degree ROADMs except the yellow sites which shall contain Multi-degree ROADM as following:

a) Site (20) four-degree ROADMs, Site (6) three-degree ROADMs, Site (17) four-degree ROADMs, Site (18) three-degree ROADMs, Site (10) five-degree ROADMs and Site (3) three-degree ROADMs.

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

b) Sites (13) and (19) required one or two nodes (platforms/equipment’s) co- located to each other in addition to an integrated seven-degree ROADMs for Site (13) and eight-degree for Site (19).

4.1.3. Sites (13,19) shall contain one platform or two co-located platforms nodes (REF. 4.1.2.B), the required connection between the co-located nodes should be optical grey 400G that can be upgraded or increased in future to 800G.

4.1.4. Sites (25) and (24) shall contain only nodes (equipment) without ROADM. These nodes should be a compact version of the main nodes (equipment) or similar to them with 100G optical line.

4.1.5. Site (23) shall contain smaller/platform daughter equipment with 10G optical line.

4.1.6. The client interfaces at each node can be groomed and aggregate and transported using OTN switching / packet fabric technology within the network using the coherent (100G) within (1 λ) and future additional (λ).

These interfaces are shown in Annex C in details with the capability to distribute or carry them (client interfaces) by using the main platform or by using platform daughter equipment co-located or integrated with the main platform.

4.1.7. An integrated OTDR (in service monitoring/live monitoring) for each link

(for the two cores) shall be integrated with the platform (equipment). The dynamic range of the OTDR shall cover and monitor the in-service fiber links.

4.1.8. The node (platform) including ROADM shall follow and not limited the list of communication standards mentioned in Annex E.

4.1.9. The (SDH) clients (services) mentioned in the Annex C are point to point connections, they are representing Clients exist in the upgraded sites in addition to current RJAF Ericsson muxes that had been considered as clients for these new nodes (platform) to facilitate the operational migration from Ericsson nodes to the new platform with proper interoperability between upgrade sites and with other regional RJAF Ericsson nodes. (REF. 3.6.12).

4.1.10. POWER

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

4.1.10.1. New power system (rectifiers, controller, relays, breakers, batteries, cables and rack) shall be added in each node site to meet the power requirements regarding these new nodes (platform, daughter equipment, etc.) in addition to the existing Ericsson nodes that use two (25A) DC circuit breakers and two (6A) DC circuit breakers for operation.

4.1.10.2. The battery set shall consist of (24) batteries, each one (2) volt with a total capacity of (600) AH at least.

4.1.10.3. The rectifier system shall be a modular system with a capacity not less than (6-8) KW with the proper load/battery circuit breakers.

4.1.11. NETWORK MANAGEMENT SYSTEM

4.1.11.1. High availability (Hot standby) NMS cluster (1+1) that can be optionally upgraded in future to (N+1) to (OAM&P) the network nodes and services through a unified GUI and common management model so operators can rapidly deploy new services and coordinate across network protocol layers to ensure efficient use of critical network assets and bandwidth optimizations with a unique integrated cross-layer management view (DWDM, OTN, Packet), therefore, the NMS shall allow RJAF to create and activate end-to-end services at the optical layers (OTN,SDH) and layer2 services such as E-LAN,E-line and E-tree.

4.1.11.2. The NMS system shall isolate and remediate faults rapidly via a multi-layer fault correlated engine.

4.1.11.3. The cluster consists of two (2) servers connected to each other using a fiber link up to (80) KM for Geo-redundant deployment.

4.1.12. FUTURE CONSIDERATIONS

4.1.12.1. The possibility to add future express (pass through) wavelengths (λ) to avoid or reduce the (O-E-O) conversion and any latency appears due to this conversion which is very useful for critical real time services and tasks. These express wavelengths are pass in many sites and dropped in other sites as shown in attached figures (Annex D, Figures 2. and Figure 3.) respectively.

This document contains information sensitive to the Government of the Hashemite Kingdom of Jordan. Distribution beyond Official US Government channels is not authorized without the express consent of the Government of the

4.1.12.2. The possibility to have or add unencrypted/encrypted coherent (100-

200) Gbps carried on the optical wavelengths mentioned in (REF 4.1.12.1).

4.1.12.3. The possibility to add future wavelengths (λ) carrying coherent

(400/600) Gbps based on a technical solution without affecting and disturbing the current working services.

4.1.13. ANCILLARY EQUIPMENT

4.1.13.1. All patch cords and installation related material shall be provided by the provider.