Important Considerations

CAUTION: Skylight orchestrator is a high-performance, real-time active system that requires special considerations to operate properly. For instance, if you install a Skylight sensor: control on the same server then hyper-threading must be disabled. 

Network Requirements

Skylight orchestrator has requirements for the data communications network. Certain protocols and ports must be supported, and sufficient bandwidth must be allocated.

The DCN interfaces with the Skylight orchestrator over one or more of its five Gigabit Ethernet ports. By default, the 10/100/1000Base-T port named MGMT is the only configured port, but the other interfaces can be enabled.

The following categories of communication need to be considered:

• End-user browser communications

• Communication with devices

• OSS communications

• Infrastructure communications

• Base communications

• Network Address Translation (NAT)

The sections that follow detail the data exchanges for each of these categories.

Note: For large installations (more than 3,000 devices), it is recommended that the data store backup file transfers be carried out using a separate physical interface. Since these backups can be large, isolating this traffic is preferable.

End-User Browser Communications

End users interact with Skylight orchestrator using a standard web browser running on their end-user workstation.

Communications will consist primarily of HTTP and HTTPS traffic initiated from the end-user workstation towards the Skylight orchestrator server. All data exchanges between end users and Skylight orchestrator will be handled via these protocols.

The following table summarizes the network requirements.

Communication With Devices

Communication between Skylight orchestrator and its managed devices (Skylight elements, Skylight sensor: control, Skylight Flex 100) involves several flows:

• Command Line Interface (CLI) sessions
  This is the primary interface used by Skylight orchestrator to establish, maintain and configure devices. It is a permanent SSH session established by Skylight orchestrator.

• SFTP sessions
  This is the main communication protocol used to exchange bulk information with devices. These sessions are temporary. They include transfer of firmware loads for upgrade information and transfer of configuration files. These sessions are initiated by the devices towards Skylight orchestrator.
  SFTP sessions are also used by Y.1564 and RFC-2544 test processes to retrieve test reports.

• Performance data streams
  This is the main communication protocol used to collect performance data from devices. These are permanent SSH connections initiated from the devices towards Skylight orchestrator. The following table summarizes the network requirements for communication between Skylight orchestrator and devices.

Note: The supported network latency between Skylight orchestrator and devices is 300ms +/- 50ms.

Managed Element Requirements (Protocol, Port, Bandwidth)

Additional Requirements of the 15K profile

Additional communications ports are required when running with a 15K deployment profile. These ports are in addition to the ports listed in Managed Element Requirements (Protocol, Port, Bandwidth).

Additional Requirements of the 30K profile

Additional communications ports are required when running with a 30K deployment profile. These ports are in addition to the ports listed in Managed Element Requirements (Protocol, Port, Bandwidth).

Additional Requirements of the 60K profile

Additional communications ports are required when running with a 60K deployment profile. These ports are in addition to the ports listed in Managed Element Requirements (Protocol, Port, Bandwidth).

Notes:

Planning guideline only. This metric varies considerably based on the specific configuration of the Metrics Collection agent. Contact Accedian support to get a more precise expected throughput based on your configuration.

Legacy nodes use passive FTP sessions for file transfers. Firewalling these sessions requires a state-aware firewall with support for Passive FTP. Skylight orchestrator’s FTP control channel is located on port 10,021. Because this is passive FTP, the devices will negotiate a second connection to Skylight orchestrator for the data channel used to transfer the file. This second connection is on a random source and destination port.

OSS Communications

OSS communications cover the network requirements to ensure that Skylight orchestrator interoperates correctly with northbound OSS systems. This section describes these network requirements for the current release of Skylight orchestrator.

Metrics Collection - Network Requirements

The data exchange is done by means of Comma Separated Value (CSV) files that are transferred from Skylight orchestrator to the northbound system.

• FTP connection from Skylight orchestrator to the OSS system for orchestrator metrics collection CSV file transfer

• SFTP connection from Skylight orchestrator to the OSS system for orchestrator metrics collection CSV file transfer

• Rsync connection from Skylight orchestrator to the OSS system for orchestrator metrics collection CSV file transfer.

The choice of flow is driven by user configuration. Also driven by user configuration is the choice to compress the CSV files before transmission. This is highly recommended as it considerably decreases the volume of data to transfer.

Since the volume and frequency of files to transfer will be high, the connection is permanent. Skylight orchestrator maintains an active connection pool to the northbound system.

The following table summarizes the network requirements for OSS communications.

Northbound Alarms - Network Requirements

Skylight orchestrator can forward alarm information to northbound OSS systems using SNMP v2 or v3 notifications and informs.

The following table summarizes the network requirements for northbound alarms.

Notes:

This value is configurable.

This is the same port used by Skylight orchestrator to transmit the inform message to the Alarm OSS. This port has a dynamic value and must be greater than 1024.

Infrastructure Communications - Network Requirements

This category of communication requirements cover Skylight orchestrator needs for generic infrastructure systems, including communication to DNS servers, NTP servers and so on.

Base Communications - Network Requirements

For explanations of the numbered notes in the table, see below.

Notes:  
¹ The SNMP agent can be used to remotely monitor the Skylight orchestrator for CPU, memory and file system usage. Temperature sensor information is also available. See SNMP Alarm Forwarding for the MIBs that can be used to provide this information. ² and ³ Other ports can be used provided they are not used for other purposes. ⁴ Default value. Can be configured in the Skylight orchestrator web interface.

Network Address Translation (NAT)

Network Address Translation (NAT) is a process by which one IP address (the internal address) is mapped or translated to another IP address (the external address). This translation happens in both data traffic directions such that the translated address is the only one that is visible to the outside world. The translation process is typically handled by a router or firewall. It is handled at the IP layer where packet IP headers are inspected and modified to switch the destination or source IP as required.

There are two basic NAT modes:

• 1:1 translation where each external address is mapped onto one internal address.
  This mode is often used when there is address duplication in the network (due to consolidation). NAT is used in this case to give hosts a unique external IP.

• 1:N translation mode where one external address is mapped to multiple internal addresses.
  This mode is used mostly to solve the issue of address exhaustion. The most common example is a residential home router, where one Internet Service Provider (ISP) address is mapped to multiple internal IPs. This allows the home to have multiple devices in its private network, but only present a single public IP address to the external world.

Skylight orchestrator supports 1:1 NAT of IP addresses for Skylight elements, and the Skylight sensor: control. A Skylight element or Skylight sensor: control can be configured with an internal IP address that remains unknown to the management plane. The external address is used to provision Skylight orchestrator and from its perspective, all communications are going to and coming from the public external IP address of the Skylight element or Skylight sensor: control.

Skylight orchestrator also supports 1:1 NAT for its own address. The IP addresses configured on a Skylight orchestrator are translated and hidden from the Skylight elements and Skylight sensor: control that it manages.

The use of 1:N NAT is not supported for Skylight elements, Skylight sensor: control and Skylight orchestrator addresses. These NAT techniques should not be used in Skylight orchestrator deployments.

Deployment Profile 

Skylight orchestrator  ships with four deployment profiles that allow it to run in small, large and very large networks. Larger profiles require more disk, CPU and memory to run. The larger profiles also have additional networking requirements.

CAUTION: If you install the Skylight sensor: control on the same server you must disable hyper-threading. CPU (vCPU) requirements of the profiles remain the same with or without hyper-threading enabled. 

For more information, see Docker Deployment Profile Configuration.

Deployment Considerations

For specific deployment considerations, see the Release Notes.