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
1.1. Open Submarine Cables
Prior to the start of the adoption of the Open Submarine Cable
model, hereafter referred to simply as Open Cables, optical
submarine cables were contracted and deployed according to
a turnkey business model, as shown in Figure 1 below. Systems
were designed and specified from end to end, comprising all
wet plant elements (cable, repeaters, and Power Feed
Equipment [PFE]) together with the transmission equipment
(the Submarine Line Terminal Equipment [SLTE]), equipped with
transponders operating with Intensity-Modulated (IM) transmit
formats and direct detection at the receiver end. System
performance could be specified using a power budget based
on Q-factor, which was directly measurable in the field to
validate system capacity and the overall performance of the
end-to-end turnkey system.
Turnkey Supply
Dry Wet
Submarine Line Power Feed
Terminating Equipment
Equipment
(SLTE)
Cable
Branching Repeaters
unit and Equalizers
Network
Management
Figure 1. Turnkey supply model
While the industry was still operating in the turnkey supply
model—the first move towards the Open Cable concept—
the disaggregation between SLTE and the wet plant came
with the emergence of the ‘upgrade’ market. Submarine
repeaters, which are actually optical amplifiers and not legacy
electrical regenerators, were first introduced in 1995. With
all-optical amplification in the wet plant, deployed system
capacity could be incremented with successive generations
of SLTE technology. For example, submarine systems, such
as Southern Cross, which was originally designed to carry an
ultimate capacity of 8 x 2.5 Gb/s, became capable of more than
80 times this original design capacity. This was achieved by
upgrading terrestrial-based transmission equipment only. New
upgrade vendors joined the submarine networking industry
and cable operators understood and appreciated the benefit
of a broader choice of SLTE technology and vendors. While the
original submarine system supply contract was still a turnkey
model with wet plant vendors providing initial SLTE, the start of
the upgrade market was the precursor to the full Open Cable
model, first introduced in 2017.
The Open Cable model requires full disaggregation of SLTE
from the wet plant, as shown in Figure 2:
• SLTE can be procured and delivered separately from the
wet plant
• The performance of the wet plant and SLTE can be defined
individually, without reference to the other.
Open Cables
SLTE
Dry Wet
Submarine Line Power Feed
Terminating Equipment
Equipment
(SLTE)
Cable
Branching Repeaters
unit and Equalizers
SLTE Network
Network Management
Management
Figure 2. Open Cable model
The enabler of the true Open Cable model was the introduction
of coherent modem technology in the SLTE transponders.
Transponders based on polarization multiplexing and multi-
level modulation formats became possible with advances
in CMOS and Digital Signal Processing (DSP) technology.
Critically, this DSP also provided the ability to compensate
all Chromatic Dispersion (CD) accumulated along the length
of any submarine system electronically in SLTE, significantly
simplifying wet plant designs.
The availability of 100 Gb/s coherent modem technology from
around 2015 was a major milestone in evolving toward Open
Cables. However, as previously mentioned, turnkey systems
were easily specified and validated via a Q-based power
budget. An Open Cable model requires quantifying wet plant
performance independently of specific SLTE or transponder
technology. Much work has been done within the industry,
notably via a SubOptic Association Working Group, to define
and standardize what is delivered in an Open Cable with new
3
parameters such as Generalized Signal-to-Noise Ratio (G-SNR)
used to evaluate wet plants and to specify system capacity
and performance.
Cross-industry collaboration has ultimately led to a common
understanding of applicable methods of specification and
testing. The ITU-T Rec. G.977.1 standard will provide agreed
upon definitions of Open Cable parameters. The SubOptic
Association Working Group document1 provides a very good
overview of the specification and acceptance criteria for
Open Cables.
The difficulty of specification and acceptance was initially a
significant deterrent in the early mass market adoption of Open
Cables. A few private cable pioneers took the plunge, seeing
the future and viewing the benefits of this model regardless
of the specification and commissioning challenges. The first
Open Cable went into service in 2017, two followed in 2018,
and three more in 2019—representing six out of 23 total new
cables in that three-year span.
However, market drivers have been clear since the advent of
the upgrade market. And now that the industry has developed a
common understanding of the new specification, the adoption
of the Open Cable model is widespread globally, including
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
90000
80000
70000
Cable kms/year
60000
50000
40000
30000
20000
10000
0 0
2016 2017 2018
RFS year
Open # Total #
Figure 3. Comparison of open versus turnkey systems (2016 – 2022)
1.2. From Open Cables to Open Cable Management
In parallel with the evolution to Open Cables, submarine
network configurations have evolved from traditional point-
to-point Cable Landing Station (CLS) to CLS-based networks
to increasingly complex networks incorporating multiple
submarine cable segments that extend from the CLS over
terrestrial backhaul networks to the Point of Presence (PoP)
or the Data Center (DC) to create a mesh network comprising
both submarine and terrestrial links. It is precisely this evolution
of the global end-to-end network that was the market driver for
Ciena’s pioneering GeoMesh Extreme network solution.
Considering such integrated and complex networks, operators
want to manage the submarine link as a segment like any other
within a global mesh network of terrestrial and submarine
links. Multiple diverse paths provide built-in redundancy and
automatic restoration to mitigate inevitable faults.
Cable operators want the benefits of intelligent automation, the
ability to monitor the performance of all network elements, and
the use of data-driven analytics to track and identify sources
of potential failure before they happen. This preventative
maintenance ultimately results in an improved network
availability, which is very important, as the global submarine
network is critical infrastructure.
16
14
Number of new systems/year
12
10
8
6
4
2
2019 2020 2021 2022
Open kms Total kms
4
Ciena’s Adaptive Network™ effectively incorporates terrestrial
and submarine links by utilizing the Open Cable concept,
encompassing the management of all system elements within
the network infrastructure, a concept termed Open Cable
Management. As shown in Figure 2, the Domain Controller for
wet plant elements is distinct from SLTE and terrestrial network
management. The status and monitoring of wet plant elements
(PFE, cable, repeaters, and branching units) is only visible on
that one Domain Controller. Control of wet plants elements is
only possible from the wet plant vendors’ Domain Controller.
There is no ‘single-pane-of-glass’ view of the network available
to the Network Operations Center (NOC) or system operator.
Having the complete picture of the performance of each
element in one place improves the network’s capability to
achieve optimal performance and availability. This integration
of wet plant management into the overall Domain Controller
is the principle of Open Cable Management. Achieving Open
Cable Management, and the integration of wet plant and dry
plant management, requires defining an interface specification
between the two. The most efficient and reliable way to
achieve this is via Open Application Programming Interfaces
(APIs), available on any modern Domain Controller. An industry
standard for Open Cable Management interfaces would benefit
submarine network operators by allowing for a best-in-class
multi-vendor network design.
An open interface definition allows users to understand how
to request data and how to interpret the response. Open Cable
Management interfaces must be developed with security taken
into account to ensure transactions across the interface meet
the operational requirements of end-users.
Open APIs are already available from some wet plant vendors,
such as SubCom, who announced their open interfaces
back in 20182. Ciena leveraged SubCom’s open interfaces to
provide integrated management of SubCom wet plant systems
and Ciena’s SLTE using its Manage, Control and Plan (MCP)
Domain Controller. The result is simpler end-to-end network
management for optimal operations efficiency.
The majority of the industry now sees Open Cable
Management as a logical and progressive evolution, but
it requires collaboration to create a common language to
define the wet plant elements to avoid multiple solutions and
unnecessary R&D. SubOptic has established a Working Group,
similar to the original Open Cable Working Group, whose main
goal is to precisely define an industry specification for Open
Cable Management.
This paper provides a detailed explanation of the concepts
involved and how the goal of Open Cable Management will
be achieved.
2. What is an API?
APIs are a set of routines, protocols, and tools used to build
software applications that specify how software components
and services shall interact. Open APIs facilitate application
development, such as a Domain Controller, by providing the
required building blocks to construct the application according
to an operator’s needs. Some APIs, such as Representational
State Transfer (REST), REST Configuration (RESTCONF),
Network Configuration (NETCONF), OpenFlow, and Google
Remote Procedure Call (gRPC), were specifically defined to
facilitate and broaden network management applications.
APIs provide for faster, easier, and multi-platform and -vendor
application development. With the use of APIs, Network
Element (NE) management and configurations are not bound
to the NE and vendor-specific Command Line Interface (CLI).
DevOps teams can create new software applications that can
interact with different NE types operating on different network
layers. APIs are commonly written in programming languages
that are easy to integrate with programs and scripts . Data
models are also compatible with IT compute and storage
building blocks. In short, APIs accelerate innovation.
3. Important considerations when developing an
Open Cable Management interface
Open Cable Management requires the development of two
functional blocks as shown in Figure 4, which illustrates an API
on the wet plant Domain Controller North Bound Interface (NBI)
and a Resource Adapter (RA) on the Domain Controller of SLTE
that interprets the data received from the wet plant based on a
Cable Model.
Prior to starting the development of either module, the Open
Cable Data Model must be defined to ensure the nomenclature
and syntax can be matched between the Open Cable and
the management system using it. For example, the method
used to describe the cable system, cable segment, fiber pair,
cable landing stations, branching units, repeaters, and other
managed devices, must be clearly defined and agreed upon.
These elements need to be uniquely identified for each cable
system, so that a third-party solution can manage multiple
cable systems without any confusion. As part of the device
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
ensuring security of the interface, given the third-party
software has to open and enroll the NBI. Specifications must
be defined for secure access methods for the NBI and options
such as JavaScript Object Notation (JSON) Web Tokens, Open
Authorization (OAuth), Secure Sockets Layer (SSL), and Remote
Authentication Dial-In User Service (RADIUS) provide the ability
to enable authentication credentials to secure interfaces.
4. Open Cable Data Model
Although this document will not prescribe the method for data
modeling, examples will be listed for consideration for API
development activities.
The Cable Data Model can be described in a wide range of
methods. There are some standardized methods in use today
including, but not limited to:
• YANG Model
• gNMI/gRPC
• NETCONF
• RESTCONF
• Other
Data Models are recommended to be defined in YANG, with
interfaces supported over YANG-compliant protocols (gNMI/
gRPC, NETCONF, REST, RESTCONF).
The Data Model must include all elements of the Open Cable
system, making it possible to collect alarms and data from all
devices. A preliminary list of elements to be included in the
Data Model are:
1. Cable Landing Station (CLS)
a. Physical properties such as a name or label, location via
latitude and longitude to identify each CLS
b. Segment name with number of fiber pairs terminated at
the site
c. c) Dry plant equipment situated in the CLS
i. Power Feed Equipment (PFE)
ii. Cable Supervisory/Health Monitoring Equipment
iii. Supervisory Health Scan names and identifiers for
each fiber pair
iv. Other equipment
2. Wet Plant Equipment
a. Each segment must be named and identified along with
properties such as:
i. Start and finish end-point elements (CLS or Branching
Unit (BU), or other wet plant devices as technology
develops)
ii. Number of fiber pairs supported
iii. Number of repeaters with labels and properties
for each (surface latitude and longitude are of
particular use)
b. Identification with a unique label for each BU along with:
i. Physical properties such as latitude and longitude
ii. Operations properties such as optical switching
options and DC Power Switching support
iii. Segment connection information for each BU leg
iv. A BU leg definition and fiber pair designation to define
each path through the BU including the presence of a
frequency selective element
v. Supported frequency for each path (required if there is
a frequency selective element in the path such as in a
ROADM BU)
5. Northbound interface description
It is recommended that newer generations of interfaces, such
as REST APIs, are used over older generations such as SNMP,
CORBA, or TL-1. Newer generation of interfaces allow for better
integration with modern software applications due to the ability
to process and consume the output without the additional
development that is required with interfaces, such as SNMP
or TL-1.
REST APIs are recommended for management and control
(HTTP/1.1), while Web Sockets are useful for autonomous
event notifications. Multiple options are available for data
descriptions, such as JSON or XML, but it is recommended to
limit implementations to a single option.
5.1. Functional requirements
When implementing the NBI, the following functional
requirements are suggested for consideration.
1. Events and alarms
a. A method to register API users for events and alarms to
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
Management model
The SubOptic Association is a non-profit international trade
association, open to membership from all in the industry,
whose purpose is to promote the interests of organizations
involved in the submarine telecommunications business.
For many years, SubOptic has been providing a forum for the
discussion of ideas and the advancement of good practices
including standardization of specifications that benefit the
entire industry.
As mentioned previously, one such SubOptic initiative is the
sponsorship of an Open Cables Working Group that, with
a wide cross section of support from across the industry,
established guidelines and standards for the specification of
performance of an Open Cable system.
SubOptic has now launched a Working Group on the
standardization of Open Cable Network Management
practices, so that integration of wet plant status and
measurements into SLTE Domain Controllers will be possible
between any vendor’s wet plant and any vendor’s SLTE.
9. Conclusion
The use of Open APIs enables submarine cable operators who
have embraced the Open Cable model to integrate monitoring
of an end-to-end network via a single Domain Controller
user interface. Access to all network data allows operators
to simplify operations and create apps that add value to their
business.
To ease the implementation of this evolution, it is important
that a common language exists in the definition of elements
that make up the submarine wet plant. A common Cable Data
Model and Open API structure provides the framework for this
common language in defining the wet plant elements.
Finally, the use of Open APIs allows a level of network
operations integration that provides the security and
operational ease enjoyed in the past with legacy turnkey
systems while delivering the capacity, cost advantages,
and accelerated technology innovation inherent to open
network designs.

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