Open Submarine Cable Management

Handbook
Key Considerations
Table of Contents
1. Introduction to Open Cable Management........................................................................................................ 3

1.1. Open Submarine Cables.................................................................................................................................. 3

1.2. From Open Cables to Open Cable Management................................................................................... 4

2. What is an API?............................................................................................................................................................ 5

3. Important considerations when developing an Open Cable Management interface.................... 5

4. Open Cable Data Model........................................................................................................................................... 7

5. Northbound interface description ..................................................................................................................... 7

5.1. Functional requirements.................................................................................................................................. 7

6. Implementation examples – Data model........................................................................................................... 8

6.1. Cable Landing Station....................................................................................................................................... 8

6.2. Wet plant equipment......................................................................................................................................... 8

6.2.1. Segment.................................................................................................................................................... 8

6.2.2. Branching Unit (BU)............................................................................................................................... 8

7. Implementation examples – Open API............................................................................................................... 9

7.1. API considerations............................................................................................................................................. 9

7.2. API hierarchy......................................................................................................................................................... 9

7.3. API definitions....................................................................................................................................................... 9

8. Standardization of an Open Cable Management model............................................................................ 10

9. Conclusion..................................................................................................................................................................... 10

10. Glossary of terms ...................................................................................................................................................... 11

11. References.................................................................................................................................................................... 11

2
1. Introduction to Open Cable Management of a broader choice of SLTE technology and vendors. While the
1.1. Open Submarine Cables original submarine system supply contract was still a turnkey
Prior to the start of the adoption of the Open Submarine Cable model with wet plant vendors providing initial SLTE, the start of
model, hereafter referred to simply as Open Cables, optical the upgrade market was the precursor to the full Open Cable
submarine cables were contracted and deployed according to model, first introduced in 2017.
a turnkey business model, as shown in Figure 1 below. Systems
The Open Cable model requires full disaggregation of SLTE
were designed and specified from end to end, comprising all
from the wet plant, as shown in Figure 2:
wet plant elements (cable, repeaters, and Power Feed
Equipment [PFE]) together with the transmission equipment • SLTE can be procured and delivered separately from the
(the Submarine Line Terminal Equipment [SLTE]), equipped with wet plant
transponders operating with Intensity-Modulated (IM) transmit • The performance of the wet plant and SLTE can be defined
formats and direct detection at the receiver end. System individually, without reference to the other.
performance could be specified using a power budget based
on Q-factor, which was directly measurable in the field to Open Cables
validate system capacity and the overall performance of the SLTE
Dry Wet
end-to-end turnkey system.

Turnkey Supply
Dry Wet Submarine Line Power Feed
Terminating Equipment
Equipment
(SLTE)
Cable

Branching Repeaters
Submarine Line Power Feed unit and Equalizers
Terminating Equipment
Equipment
SLTE Network
(SLTE)
Network Management
Cable Management

Branching Repeaters
unit and Equalizers
Figure 2. Open Cable model
Network
Management
The enabler of the true Open Cable model was the introduction
of coherent modem technology in the SLTE transponders.
Figure 1. Turnkey supply model Transponders based on polarization multiplexing and multi-
level modulation formats became possible with advances
While the industry was still operating in the turnkey supply in CMOS and Digital Signal Processing (DSP) technology.
model—the first move towards the Open Cable concept— Critically, this DSP also provided the ability to compensate
the disaggregation between SLTE and the wet plant came all Chromatic Dispersion (CD) accumulated along the length
with the emergence of the ‘upgrade’ market. Submarine of any submarine system electronically in SLTE, significantly
repeaters, which are actually optical amplifiers and not legacy simplifying wet plant designs.
electrical regenerators, were first introduced in 1995. With
all-optical amplification in the wet plant, deployed system The availability of 100 Gb/s coherent modem technology from
capacity could be incremented with successive generations around 2015 was a major milestone in evolving toward Open
of SLTE technology. For example, submarine systems, such Cables. However, as previously mentioned, turnkey systems
as Southern Cross, which was originally designed to carry an were easily specified and validated via a Q-based power
ultimate capacity of 8 x 2.5 Gb/s, became capable of more than budget. An Open Cable model requires quantifying wet plant
80 times this original design capacity. This was achieved by performance independently of specific SLTE or transponder
upgrading terrestrial-based transmission equipment only. New technology. Much work has been done within the industry,
upgrade vendors joined the submarine networking industry notably via a SubOptic Association Working Group, to define
and cable operators understood and appreciated the benefit and standardize what is delivered in an Open Cable with new

3
parameters such as Generalized Signal-to-Noise Ratio (G-SNR) 1.2. From Open Cables to Open Cable Management
used to evaluate wet plants and to specify system capacity In parallel with the evolution to Open Cables, submarine
and performance. network configurations have evolved from traditional point-
to-point Cable Landing Station (CLS) to CLS-based networks
Cross-industry collaboration has ultimately led to a common to increasingly complex networks incorporating multiple
understanding of applicable methods of specification and submarine cable segments that extend from the CLS over
testing. The ITU-T Rec. G.977.1 standard will provide agreed terrestrial backhaul networks to the Point of Presence (PoP)
upon definitions of Open Cable parameters. The SubOptic or the Data Center (DC) to create a mesh network comprising
Association Working Group document1 provides a very good both submarine and terrestrial links. It is precisely this evolution
overview of the specification and acceptance criteria for of the global end-to-end network that was the market driver for
Open Cables. Ciena’s pioneering GeoMesh Extreme network solution.

The difficulty of specification and acceptance was initially a Considering such integrated and complex networks, operators
significant deterrent in the early mass market adoption of Open want to manage the submarine link as a segment like any other
Cables. A few private cable pioneers took the plunge, seeing within a global mesh network of terrestrial and submarine
the future and viewing the benefits of this model regardless links. Multiple diverse paths provide built-in redundancy and
of the specification and commissioning challenges. The first automatic restoration to mitigate inevitable faults.
Open Cable went into service in 2017, two followed in 2018,
and three more in 2019—representing six out of 23 total new Cable operators want the benefits of intelligent automation, the
cables in that three-year span. ability to monitor the performance of all network elements, and
the use of data-driven analytics to track and identify sources
However, market drivers have been clear since the advent of of potential failure before they happen. This preventative
the upgrade market. And now that the industry has developed a maintenance ultimately results in an improved network
common understanding of the new specification, the adoption availability, which is very important, as the global submarine
of the Open Cable model is widespread globally, including network is critical infrastructure.
private and large consortia submarine cables. Ciena estimates
that 85 percent of the planned cable-kilometers in the next
three years will be based on an Open Cable model.

Open Systems vs. Total Systems

100000 16

90000
14

Number of new systems/year

80000
12
70000
Cable kms/year

10
60000

50000 8

40000
6
30000
4
20000
2
10000

0 0
2016 2017 2018 2019 2020 2021 2022
RFS year

Open # Total # Open kms Total kms

Figure 3. Comparison of open versus turnkey systems (2016 – 2022)

4
Ciena’s Adaptive Network™ effectively incorporates terrestrial This paper provides a detailed explanation of the concepts
and submarine links by utilizing the Open Cable concept, involved and how the goal of Open Cable Management will
encompassing the management of all system elements within be achieved.
the network infrastructure, a concept termed Open Cable
Management. As shown in Figure 2, the Domain Controller for 2. What is an API?
wet plant elements is distinct from SLTE and terrestrial network APIs are a set of routines, protocols, and tools used to build
management. The status and monitoring of wet plant elements software applications that specify how software components
(PFE, cable, repeaters, and branching units) is only visible on and services shall interact. Open APIs facilitate application
that one Domain Controller. Control of wet plants elements is development, such as a Domain Controller, by providing the
only possible from the wet plant vendors’ Domain Controller. required building blocks to construct the application according
There is no ‘single-pane-of-glass’ view of the network available to an operator’s needs. Some APIs, such as Representational
to the Network Operations Center (NOC) or system operator. State Transfer (REST), REST Configuration (RESTCONF),
Network Configuration (NETCONF), OpenFlow, and Google
Having the complete picture of the performance of each
Remote Procedure Call (gRPC), were specifically defined to
element in one place improves the network’s capability to
facilitate and broaden network management applications.
achieve optimal performance and availability. This integration
of wet plant management into the overall Domain Controller APIs provide for faster, easier, and multi-platform and -vendor
is the principle of Open Cable Management. Achieving Open application development. With the use of APIs, Network
Cable Management, and the integration of wet plant and dry Element (NE) management and configurations are not bound
plant management, requires defining an interface specification to the NE and vendor-specific Command Line Interface (CLI).
between the two. The most efficient and reliable way to DevOps teams can create new software applications that can
achieve this is via Open Application Programming Interfaces interact with different NE types operating on different network
(APIs), available on any modern Domain Controller. An industry layers. APIs are commonly written in programming languages
standard for Open Cable Management interfaces would benefit that are easy to integrate with programs and scripts . Data
submarine network operators by allowing for a best-in-class models are also compatible with IT compute and storage
multi-vendor network design. building blocks. In short, APIs accelerate innovation.

An open interface definition allows users to understand how

3. Important considerations when developing an
to request data and how to interpret the response. Open Cable
Open Cable Management interface
Management interfaces must be developed with security taken
into account to ensure transactions across the interface meet Open Cable Management requires the development of two
the operational requirements of end-users. functional blocks as shown in Figure 4, which illustrates an API
on the wet plant Domain Controller North Bound Interface (NBI)
Open APIs are already available from some wet plant vendors, and a Resource Adapter (RA) on the Domain Controller of SLTE
such as SubCom, who announced their open interfaces that interprets the data received from the wet plant based on a
back in 20182. Ciena leveraged SubCom’s open interfaces to Cable Model.
provide integrated management of SubCom wet plant systems
and Ciena’s SLTE using its Manage, Control and Plan (MCP) Prior to starting the development of either module, the Open
Domain Controller. The result is simpler end-to-end network Cable Data Model must be defined to ensure the nomenclature
management for optimal operations efficiency. and syntax can be matched between the Open Cable and
the management system using it. For example, the method
The majority of the industry now sees Open Cable used to describe the cable system, cable segment, fiber pair,
Management as a logical and progressive evolution, but cable landing stations, branching units, repeaters, and other
it requires collaboration to create a common language to managed devices, must be clearly defined and agreed upon.
define the wet plant elements to avoid multiple solutions and
unnecessary R&D. SubOptic has established a Working Group, These elements need to be uniquely identified for each cable
similar to the original Open Cable Working Group, whose main system, so that a third-party solution can manage multiple
goal is to precisely define an industry specification for Open cable systems without any confusion. As part of the device
Cable Management. description, port identification is required to assist in building

5
 Cable System with Branching Units nomenclature, and
SLTE NMS syntax needed
CLS CLS
A BU01 BU02 BU03 Z to access the
API Wet Plant NMS
Cable Model CLS CLS CLS data model.
Cable Branch B Branch C Branch D
System
Resource Cable Model API Wet Plant NMS
Cable System with Branching Units The user of the NBI
Adapter
Cable Model
CLS CLS
is typically another
API Wet Plant NMS A Z
BU01 BU02 BU03 Domain Controller,
which displays
Import

CLS CLS CLS

Branch B Branch C Branch D
the managed
Cable System with Branching Units
Cable Data equipment, both
CLS CLS terrestrial and
Cable Data A BU01 BU02 BU03 Z
submarine, along
Cable Data CLS CLS CLS
Branch B Branch C Branch D with the cable
system(s) in one
Figure 4. Open Cable Management interface structure
unified (single-pane-of-glass) management interface for
end‑users. There is a desire to have geographical information
channel paths through the cable system. This allows for the
for Open Cable elements to facilitate its display on a world map
correct interpretation of alarms raised by the cable system
view. [See figure 5]
to ensure they are correctly modeled and displayed in the
implementation being developed.
The intent of this type of solution is to identify issues at the
network level and narrow down the alarm profile to isolate
The definition of these devices is one area where the SubOptic
the root cause as quickly as possible. Although the NBI might
Open Cable Management Working Group can provide
have the capability to provision elements (SET commands)
benefits to the industry via a group of industry experts to
in the cable system, the normal intent of usage for a Domain
offer guidance.
Controller is surveillance via read-only functions (GET
A description of the NBI is required that includes the details commands). While NBIs may implement SET commands, the
of the specific interface provided by the wet plant vendor. expectation is that most will not, so when an issue is isolated to
This description is dependent on the type of interface a specific cable system, the NOC operator would use the cable
implemented for the NBI (REST, OpenConfig, gNMI/gRPC, system Domain Controller for executing remediation actions,
NETCONF, RESTCONF, etc.) and would reflect the terminology, including changing settings, provisioning devices, or other
mitigation actions.

Bubbles expand when zoomed out to show

underlying repeaters/BUs and span

Alarms are displayed for each item:

SLTE, repeaters, BU, and new devices

Figure 5. Open Cable elements in map view

6
The NBI description must include one or more methods 2. Wet Plant Equipment
ensuring security of the interface, given the third-party
a. Each segment must be named and identified along with
software has to open and enroll the NBI. Specifications must
properties such as:
be defined for secure access methods for the NBI and options
such as JavaScript Object Notation (JSON) Web Tokens, Open i. Start and finish end-point elements (CLS or Branching
Authorization (OAuth), Secure Sockets Layer (SSL), and Remote Unit (BU), or other wet plant devices as technology
Authentication Dial-In User Service (RADIUS) provide the ability develops)
to enable authentication credentials to secure interfaces. ii. Number of fiber pairs supported
iii. Number of repeaters with labels and properties
for each (surface latitude and longitude are of
4. Open Cable Data Model
particular use)
Although this document will not prescribe the method for data
modeling, examples will be listed for consideration for API b. Identification with a unique label for each BU along with:
development activities. i. Physical properties such as latitude and longitude
ii. Operations properties such as optical switching
The Cable Data Model can be described in a wide range of
options and DC Power Switching support
methods. There are some standardized methods in use today
iii. Segment connection information for each BU leg
including, but not limited to:
iv. A BU leg definition and fiber pair designation to define
• YANG Model each path through the BU including the presence of a
• gNMI/gRPC frequency selective element
v. Supported frequency for each path (required if there is
• NETCONF
a frequency selective element in the path such as in a
• RESTCONF ROADM BU)
• Other
5. Northbound interface description
Data Models are recommended to be defined in YANG, with It is recommended that newer generations of interfaces, such
interfaces supported over YANG-compliant protocols (gNMI/ as REST APIs, are used over older generations such as SNMP,
gRPC, NETCONF, REST, RESTCONF). CORBA, or TL-1. Newer generation of interfaces allow for better
integration with modern software applications due to the ability
The Data Model must include all elements of the Open Cable to process and consume the output without the additional
system, making it possible to collect alarms and data from all development that is required with interfaces, such as SNMP
devices. A preliminary list of elements to be included in the or TL-1.
Data Model are:
REST APIs are recommended for management and control
1. Cable Landing Station (CLS) (HTTP/1.1), while Web Sockets are useful for autonomous
a. Physical properties such as a name or label, location via event notifications. Multiple options are available for data
latitude and longitude to identify each CLS descriptions, such as JSON or XML, but it is recommended to
b. Segment name with number of fiber pairs terminated at limit implementations to a single option.
the site
5.1. Functional requirements
c. c) Dry plant equipment situated in the CLS
When implementing the NBI, the following functional
i. Power Feed Equipment (PFE) requirements are suggested for consideration.
ii. Cable Supervisory/Health Monitoring Equipment
iii. Supervisory Health Scan names and identifiers for 1. Events and alarms
each fiber pair
a. A method to register API users for events and alarms to
iv. Other equipment
be forwarded autonomously
b. Autonomous push of events and alarms from the Domain
Controller NBI to registered API users

7
 c. An API command to retrieve events and alarms for
{
synchronization purposes (after an interruption such as a
“cableLandingStations”: [
loss of communication channel or equivalent event) {
“name”: “CLS1”,
2. API support
“latitude”: “0.0”,
a. Support for standard authentication methods for API “longitude”: “0.0”,
“terminationData”: {
users
“id”: “1”,
b. Both retrieval and provisioning of data via a defined and “segment”: “S1”,
documented set of commands for each API “fiberPairId”: “1”,
c. Version management method for APIs to ensure “terminatingFiberPairId”: “1”
}
synchronization with users over API upgrades, etc. }
d. Creation of APIs for a single piece of equipment or group ]
of equipment }
e. APIs for wet plant status and surveillance are deemed
high priority for Open Cable support 6.2. Wet plant equipment
The wet plant data comprises Segments that encapsulate the
3. Generic
number of fiber pairs and the devices belonging to a fiber pair. It
a. Time synchronization shall use Network Time Protocol also comprises the BUs. The following sections illustrate how a
(NTP) segment and BU could be defined in JSON.
b. The file transfer interface shall support SCP or Secure File
Transfer Protocol (SFTP) 6.2.1. Segment 6.2.2. Branching Unit (BU)
c. NE user interfaces shall use Secure Shell (SSH)
d. RADIUS or TACACS+ shall be used to support remote { {
“segments”: [ “branchingUnits”: [
Authentication, Authorization, and Accounting (AAA)
{ {
“id”: “1”, “id”: “1”,
6. Implementation examples – Data model “name”: “S1”, “name”: “FP1”,
This section provides examples of how a data model may “start”: “CLS1”, “cableStation”: “CLS1”,
be put together for different types of equipment. In these “end”: “BU1”, “latitude”: “0.0”,
“fiberPairs”: [ “longitude”: “0.0”,
examples, JSON is used for the data description. { “buLegs”: [
“id”: “1”, {
“name”: “FP1”, “name”: “Trunk”,
“devices”: [ “direction”: “CLS1”,
S1 S3 { “fiberPairs”: [
Trunk BU1 A1 “name”: “Rep01”, {
CLS 1 CLS 2 “latitude”: “0.0”, “id”: “1”,
“longitude”: “0.0”, “farEndSegment”: “S2”,
S2 “type”: “Repeater” “farEndFiberPair”: “1”
A2 }, }
{ ]
“name”: “Rep02”, },
“latitude”: “0.0”, {
“longitude”: “0.0”, “name”: “A1”,
CLS 3
“type”: “Repeater” “direction”: “CLS2”,
Figure 6. Sample Configuration } “fiberPairs”: [
] {
} “id”: “1”,
6.1. Cable Landing Station ] “farEndSegment”: “S1”,
} “farEndFiberPair”: “1”
The CLS object comprises the segments and fiber pairs that ] }
terminate at a CLS, in addition to some other key attributes } ]
like latitude, longitude, etc. The following data depicts how a }
]
sample CLS could be defined in JSON.
}
]
}

8
7. Implementation examples – Open API 7.3. API definitions
7.1. API considerations
Any API can be easily consumed and accessed by as many API Name HTTP Method Description
different clients as required. The following items should Get Active and cleared
GET
be considered when implementing the APIs. While the Alarms alarms
functionality described should be available from any protocol, DELETE Delete or clear Alarms
the examples below are based on REST commands. Get equipment
GET configuration of managed
• API must follow basic security protocol elements
Control
• Media type definitions should be in compliance with Provide configuration
RFC 6838 PUT capability of managed
elements
• HTTP Status Codes should be in compliance with RFC 6838
Get any occurrence of
Events GET
• The API should follow the proper versioning Events

• The API data model should follow the proper schema ruleset Get current and historical
Inventories GET
inventories
• HTTP methods should be as per standard:
Managed
GET Get all managed elements
Elements
HTTP Create, Read,
Action
method Update, Delete Get current path and
Measurement GET
GET read returns requested data voltage
POST create creates a new record Get snapshots, status
GET
PUT or Performance history and threshold
update updates an existing record
PATCH PUT Edit the threshold values
DELETE delete deletes an existing record Get managed station
Stations GET
names for a cable system

7.2. API hierarchy

Alarms

Managed Elements Performance

Cable System Shelves Measurement

Inventories Control

Equipments Events

Cable Stations Alarms

Config

Figure 7. Illustrated Application Programming Interface (API) Hierarchy

9
8. Standardization of an Open Cable 9. Conclusion
Management model The use of Open APIs enables submarine cable operators who
The SubOptic Association is a non-profit international trade have embraced the Open Cable model to integrate monitoring
association, open to membership from all in the industry, of an end-to-end network via a single Domain Controller
whose purpose is to promote the interests of organizations user interface. Access to all network data allows operators
involved in the submarine telecommunications business. to simplify operations and create apps that add value to their
For many years, SubOptic has been providing a forum for the business.
discussion of ideas and the advancement of good practices
including standardization of specifications that benefit the To ease the implementation of this evolution, it is important
entire industry. that a common language exists in the definition of elements
that make up the submarine wet plant. A common Cable Data
As mentioned previously, one such SubOptic initiative is the Model and Open API structure provides the framework for this
sponsorship of an Open Cables Working Group that, with common language in defining the wet plant elements.
a wide cross section of support from across the industry,
established guidelines and standards for the specification of Finally, the use of Open APIs allows a level of network
performance of an Open Cable system. operations integration that provides the security and
operational ease enjoyed in the past with legacy turnkey
SubOptic has now launched a Working Group on the systems while delivering the capacity, cost advantages,
standardization of Open Cable Network Management and accelerated technology innovation inherent to open
practices, so that integration of wet plant status and network designs.
measurements into SLTE Domain Controllers will be possible
between any vendor’s wet plant and any vendor’s SLTE.

The goal of the Working Group is to develop an Open Cable

Network Management model that includes recommendations Open Submarine Cables Handbook – Gain more insights
for standard APIs. These APIs will be used to manage the
undersea plant, along with its related equipment. Such APIs
will govern basic functionality such as alarm management,
configuration/provisioning, performance and baseline
monitoring, and security, along with addressing optional
special commands for unique operations.

Ciena is a member of this Working Group, along with other

industry subject matter experts from content providers, wet
plant and SLTE vendors, and cable operators.

10
10. Glossary of terms 11. References
AAA Authentication, Authorization, and Accounting 1.  Subsea Open Cables: A Practical Perspective on the
API Application Programming Interface Guidelines and Gotchas submitted to SubOptic 2019.
BU Branching Unit
CLS Cable Landing Station 2. T
 E SubCom announces Ocean Control suite, first offering
gNMI Network Management Interface (Google-based of full network programmability for undersea domain, May
version) 8, 2018.
gRPC Remote Procedure Call (Google based open
source solution)
HTTP(S) Hypertext Transfer Protocol (Secure)
JSON JavaScript Object Notation
NBI North Bound Interface
NETCONF Network Configuration Protocol (IETF standard)
NOC Network Operations Center
NTP Network Time Protocol
OADM Optical Add Drop Multiplexor
PFE Power Feed Equipment
RADIUS Remote Authentication Dial-In User Service
REST RESTful – Representational State Transfer
RESTCONF IETF RFC 8040 solution prescribing a YANG
model with NETCONF protocol for an API
RPTR Repeater
SCP Secure Copy Protocol
SFTP Secure File Transfer Protocol
SNMP Simple Network Management Protocol
SSH Secure Shell
TACACS(+) Terminal Access Controller Access-Control
System (+ is a newer version largely replacing the
old)
WSS Wavelength Selective Switch
XML Extensible Mark-up Language
YANG Yet Another Next Generation (data modelling
language) a modern approach for a data model
from IETF

Ciena may make changes at any time to the products or specifications contained herein without notice. Ciena and the Ciena Logo are trademarks or registered trademarks of Ciena
Corporation in the U.S. and other countries. A complete list of Ciena’s trademarks is available at www.ciena.com. Third-party trademarks are the property of their respective owners
and do not imply a partnership between Ciena and any other company. Copyright © 2021 Ciena® Corporation. All rights reserved. 1.2021