Internet DRAFT - draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk
draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk
Internet Engineering Task Force R. Kunze, Ed.
Internet-Draft Deutsche Telekom
Intended status: Informational G. Grammel, Ed.
Expires: January 25, 2020 Juniper
D. Beller
Nokia
G. Galimberti, Ed.
Cisco
J. Meuric
Orange
July 24, 2019
A framework for Management and Control of DWDM optical interface
parameters
draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13
Abstract
The control and management of DWDM interfaces are a precondition for
enhanced multilayer networking. They are needed to ensure an
efficient data transport, to meet the requirements requested by
today's IP-services and to provide a further automation of network
provisioning and operations. This document describes use cases,
requirements and solutions for the control and management of optical
interface parameters according to different types of single channel
DWDM interfaces. The focus is on automating the network provisioning
process irrespective on how it is triggered i.e. by Element Manager
System (EMS), Network Management System (NMS) or Generalized Multi
Protocol Label Switching (GMPLS). This document covers management
and control considerations in different scenarios of single channel
DWDM interfaces. The purpose is to identify the necessary
information and processes to be used by control or management systems
to properly and efficiently drive the network.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
Kunze, et al. Expires January 25, 2020 [Page 1]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 25, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4
3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Comparison of Approaches for Transverse Compatibility . . 6
3.1.1. Multivendor DWDM Line System with Transponders . . . 6
3.1.2. Integrated Single Channel DWDM Deployments on the
Client Site . . . . . . . . . . . . . . . . . . . . . 7
4. Solutions for Managing and Controlling Single Channel Optical
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Separate Operation and Management Approaches . . . . . . 10
4.1.1. Direct Connection to the Management System . . . . . 10
4.1.2. Indirect Connection to the DWDM Management System
(First Optical Node) . . . . . . . . . . . . . . . . 11
4.2. Control Plane Considerations . . . . . . . . . . . . . . 13
4.2.1. Considerations Using GMPLS Signaling . . . . . . . . 14
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 21
A.1. Optical interface parameter collection . . . . . . . . . 21
A.2. DWDM client - ROADM interconection discovery . . . . . . 21
A.3. Service Setup . . . . . . . . . . . . . . . . . . . . . . 21
Kunze, et al. Expires January 25, 2020 [Page 2]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
A.4. Link Monitoring Use Cases . . . . . . . . . . . . . . . . 22
A.4.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 25
A.4.2. Power Control Loop Use Case . . . . . . . . . . . . . 27
A.5. Optical Circuit restoration . . . . . . . . . . . . . . . 29
A.6. Multilayer restoration . . . . . . . . . . . . . . . . . 29
Appendix B. Detailed info drafts . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction
The usage of external single channel Dense Wavelenght Division
Multiplexing (DWDM) interfaces (e.g. in routers) connected to a DWDM
Network (e.g. router connected to a network of Reconfigurable Optical
Add Drop Multiplexers (ROADM) and optical amplifiers) adds a further
networking option for operators but requires an harmonised control
and management plane interaction between the different network
domains.
Carriers deploy their networks today based on transport and packet
network infrastructures as domains to ensure high availability and a
high level of redundancy combining the Packet and Transport
restoration. Both network domains were operated and managed
separately. This is the status quo in many carrier networks today.
In the case of deployments where the optical transport interface
moves into the client device (e.g. router) an interaction between
those domains becomes necessary (e.g. Lambda reprovisioning due to
an optical restoration).
This framework specifies different levels of control and management
plane interaction to support the usage of single channel optical
interfaces in carrier networks in an efficient manner. The
interfaces between the two layers can be either gray or coloured.
Although Optical routing and wavelength assignment based on
Wavelenght Switched Optical Network (WSON) is out of scope, they can
benefit from the optical parameters that are exchanged between the
Client and the DWDM Network. Also, the wavelength ordering process
and determining the demand for a new wavelength path through the
network are out of scope. The GMPLS and PCE functions will use the
information collected from the Client and the DWDM network, the
definition on how PCE and GMPLS can use the information and cooperate
to implement RWA and circuit/service provisioning ar aout of scope of
this document.
Note that the Control and Management Planes are two separate entities
that may handle the same information in different ways.
Kunze, et al. Expires January 25, 2020 [Page 3]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP_14, RFC 2119 [RFC2119], RFC 8174 [RFC8174] when, and only when,
they appear in all capitals, as shown here.
While RFC 2119 [RFC2119] RFC 8174 [RFC8174] describe interpretations
of these key words in terms of protocol specifications and
implementations, they are used in this document to describe design
requirements for protocol extensions.
2. Terminology and Definitions
The current generation of Wavelenght Division Multiplexing (WDM)
networks are single vendor networks where the optical line system and
the transponders are tightly integrated. The DWDM interface
migration from integrated transponders to third party transponders or
colored interfaces change this scenario and introduces a standardized
interface at the level of OCh between the DWDM interface and the DWDM
network.
Black Link: The Black Link [ITU-T.G.698.2] allows supporting an
optical transmitter/receiver pair (of a single vendor or from
different vendors) to provide a single optical channel interface and
transport it over an optical network composed of amplifiers, filters,
add-drop multiplexers these being possibly from different vendors.
Therefore the standard defines the ingress and egress parameters for
the optical interfaces at the reference points Source side (Ss) and
Receive side (Rs).
Single Channel DWDM Interface: The single channel interfaces to DWDM
systems defined in [ITU-T.G.698.2], which currently include the
following features: channel frequency spacing: 50 GHz and wider
(defined in [ITU-T.G.694.1] ); bit rate of single channel: Up to 100
Gbit/s. Future revisions are expected to include application codes
for bit rates up to 400 Gbit/s.
Forward Error Correction (FEC): FEC is a way of improving the
performance of high-capacity optical transmission systems. Employing
FEC in optical transmission systems yields system designs that can
accept relatively large BER (much more than 10^-12) in the optical
transmission line (before decoding).
Administrative domain [ITU-T.G.805]: the extent of resources which
belong to a single player such as a network operator, a service
Kunze, et al. Expires January 25, 2020 [Page 4]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
provider or an end-user. Administrative domains of different players
do not overlap amongst themselves.
Intra-domain interface (IaDI) [ITU-T.G.872]: A physical interface
within an administrative domain.
Inter-domain interface (IrDI) [ITU-T.G.872]: A physical interface
that represents the boundary between two administrative domains.
Management Plane [ITU-T.G.8081],: The management plane performs
management functions for the transport plane, the control plane and
the system as a whole. It also provides coordination between all the
planes. The following management functional areas are performed in
the management plane: performance management, fault management,
configuration management, accounting management and security
management.
Control Plane [ITU-T.G.8081]: Through signaling, the control plane
sets up and releases connections, may restore a connection in case of
a failure, and also performs other functions (e.g., neighbor
discovery, topology distribution) in support of those.
Transponder: A Transponder is a network element that performs O/E/O
(Optical /Electrical/Optical) conversion. In this document it is
referred only transponders with 3R (rather than 2R or 1R
regeneration) as defined in [ITU-T.G.872].
Line System: A Line System is a portion of the network including
Reconfigurable Add Drop Multiplexers (ROADM) Line Amplifiers and the
the fibers connecting them.
Client DWDM interface: A Transceiver element that performs E/O
(Electrical/Optical) conversion. In this document it is referred as
the DWDM side of a transponder as defined in [ITU-T.G.872].
3. Solution Space
The solution space of this document is focusing on aspects related to
the management and control of single-channel optical interface
parameters of physical point-to-point and ring DWDM applications on
single-mode optical fibres and allows the direct connection of a wide
variety of equipment using a DWDM link, for example
1. A digital cross-connect with multiple optical interfaces,
supplied by a different vendor from the line system
2. Devices as routing, switching or compute nodes, each from a
different vendor, providing optical line interfaces
Kunze, et al. Expires January 25, 2020 [Page 5]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
3. A set of Data Center Equipment and servers
4. A combination of the above
3.1. Comparison of Approaches for Transverse Compatibility
This section describes two ways to achieve transverse compatibility.
Section 3.1.1 describes the classic model based on well defined
inter-domain interfaces. Section 3.1.2 defines a model ensuring
interoperability on the line side of the optical network.
3.1.1. Multivendor DWDM Line System with Transponders
As illustrated in Figure 1, for this approach interoperability is
achieved via the use of optical transponders providing OEO (allowing
conversion to appropriate parameters). The optical interfaces can
then be any short reach standardized optical interface that both
vendors support, such as those found in [ITU-T.G.957], [ITU-T.G.691],
[ITU-T.G.693], etc.
IrDI IaDI
| |
. .
| +----------------------------|----+
. | + WDM Domain + . |
| | |\ /| | |
+------+ . | | \ |\ / | . | +------+
| TX/ |-->--+---+--T/-|OM|----|/-------|OD|--+-\T-+---->--| RX/ |
| RX |--<--+---+--T/-| |----- /|-----| |--.-\T-+----<--| TX |
+------+ | | | / \| \ | | | +------+
. | |/ \| . |
| | + + | |
. +----------------------------.----+
| |
TX/RX = Single channel non-DWDM interfaces
T/ = Transponder
OM = Optical Mux
OD = Optical Demux
Figure 1: Inter and Intra-Domain Interface Identification
In the scenario of Figure 1 the administrative domain is defined by
the Interdomain Interface (IrDI). This interface terminates the DWDM
Kunze, et al. Expires January 25, 2020 [Page 6]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
domain. The line side is characterized by the Intradomanin Interface
(IaDI). This interface specifies the internal parameter set of the
optical administrative domain. In the case of a client DWDM
interface deployment this IaDI moves into the client device and
extends the optical and administrative domain towards the client
node. [ITU-T.G.698.2] for example specifies a set of parameter set
for a certain set of applications, see Section 3.1.2.
This document elaborates only the IaDI (Intra Domain Interface) as
shown in Figure 1 as DWDM transversely compatible and multi-vendor
interface within one administrative domain controlled by the network
operator.
SNMP/Simple Management Interface (SMI), NETCONF/RESTCONF and Link
Management Protocol (LMP) TLV to support the direct exchange of
information between the client and the network management and control
plane will be specified in further documents.
The YANG based NETCONF and RESTCONF protocol are better suited for
creating and modifying configuration state and thus RECOMMENDED to be
used over SNMP MIB. The SNMP MIB creating and modifying
configuration state could be used for legacy network.
3.1.2. Integrated Single Channel DWDM Deployments on the Client Site
In case of a deployment as shown in Figure 2, through the use of DWDM
interfaces, multi-vendor interconnection can also be achieved. Among
the possible use cases, it may be used to remove the need for one
short reach transmitter and receiver pair per channel (eliminating
the transponders).
Kunze, et al. Expires January 25, 2020 [Page 7]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
Figure 2 shows a set of reference points, for single-channel
connection (Ss and Rs) between transmitters (Tx) and receivers (Rx).
Here the DWDM network elements include an optical multiplexer (OM)
and an optical demultiplexer (OD) (which are used as a pair with the
peer element), one or more optical amplifiers and may also include
one or more ROADMs.
|==================== Black Link =======================|
+-------------------------------------------------+
Ss | | DWDM Network Elements | | Rs
+---+ | | | \ / | | | +---+
Tx L1---|->| \ +------+ +------+ / |--|-->Rx L1
+---+ | | | | | +------+ | | | | | +---+
+---+ | | | | | | | | | | | | +---+
Tx L2---|->| OM |-|>|------|->| ROADM|--|------|->| OD |--|-->Rx L2
+---+ | | | | | | | | | | | | +---+
+---+ | | | | | +------+ | | | | | +---+
Tx L3---|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3
+---+ | | / | Link +----|--|----+ Link | \ | | +---+
+-----------+ | | +----------+
+--+ +--+
|==== Black Link ====| | |
v |
+-----+ +-----+
|RxLx | |TxLx |
+-----+ +-----+
Ss = Reference point at the DWDM network element tributary output
Rs = Reference point at the DWDM network element tributary input
Lx = Lambda x
OM = Optical Mux
OD = Optical Demux
ROADM = Reconfigurable Optical Add Drop Mux
Linear DWDM network as per ITU-T G.698.2
Figure 2: Linear Black Link
The single administrative domain may consist of several vendor
domains. Even in that case a common network management and control
is required to ensure a consistent operation and provisioning of the
entire connection.
Kunze, et al. Expires January 25, 2020 [Page 8]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
SNMP/SMI, NETCONF/RESTCONF and LMP TLV to support the direct exchange
of information between the client and the network management and
control plane will be specified in further documents.
4. Solutions for Managing and Controlling Single Channel Optical
Interface
Operation and management of WDM systems is traditionally seen as a
homogenous group of tasks that could be carried out best when a
single management system or a hierarchical management system is used.
Currently each WDM vendor provides an Element Management System (EMS)
that also provisions the wavelengths. In a multi-vendor line system,
such single-vendor EMS requirement is no more effective. New methods
of managing and controlling line systems need to be looked at.
Therefore from the operational point of view the following approaches
will be considered to manage and operate optical interfaces.
1. Separate operation and management of client device and the
transport network whereas the interface of the client belongs to
the administrative domain of the transport network and will be
managed by the transport group. This results in two different
approaches to send information to the management system
a. Direct connection from the client node to the transport
management system, ensuring a management of the DWDM interface of
the optical network (e.g. EMS, NMS)
b. Indirect connection to the management system of the optical
network using a protocol (e.g. LMP) between the client device
and the directly connected WDM system node to exchange management
information with the optical domain
2. Common operation and management of client device including the
single channel DWDM part and the Transport network
The first option keeps the status quo in large carrier networks as
mentioned above. In that case it must be ensured that the full FCAPS
Management (Fault, Configuration, Accounting, Performance and
Security) capabilities are supported. This means from the management
staff point of view nothing changes. The transceiver/receiver
optical interface will be part of the optical management domain and
will be managed from the transport management staff.
The second solution addresses the case where underlying WDM transport
network is mainly used to interconnect a homogeneous set of client
nodes (e.g. IP routers or digital crossconnects). Since the service
creation and restoration could be done by the higher layers (e.g.
Kunze, et al. Expires January 25, 2020 [Page 9]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
IP), this may lead to an efficient network operation and a higher
level of integration.
4.1. Separate Operation and Management Approaches
4.1.1. Direct Connection to the Management System
As depicted in Figure 3 (case 1a) one possibility to manage the
optical interface within the client domain is a direct connection to
the management system of the optical domain. This ensures
manageability as usual.
+-----+
| NMS |
|_____|
/_____/
|
|
|
+---+---+
+----->+ EMS |
/ | |
/ +-------+
/ | MI SNMP or NETCONF/RESTCONF
SNMP / or NETCONF | DCN Network
--------------------+-------------------------------
/ +------+-----------------------+
/ | +| WDM Domain + |
/ | |\ /| |
+---+--+ | | \ |\ / | | +------+
| CL |-/C------+-----|OM|----|/-------|OD|----+-------/C-| CL |
| |-/C------+-----| |----- /|-----| |----+-------/C-| |
+------+ | | / \| \ | | +------+
| |/ \| |
| + + |
+------------------------------+
CL = Client Device
/C = Single Channel Optical Interface
OM = Optical Mux
OD = Optical Demux
EMS = Element Management System
MI = Management Interface
DCN = Data Control Network
Figure 3: Connecting Single Channel optical interfaces to the
Transport Management system
Kunze, et al. Expires January 25, 2020 [Page 10]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
The exchange of management information between client device and the
management system assumes that some form of a direct management
communication link exists between the client device and the DWDM
management system (e.g. EMS). This may be an Ethernet Link or a DCN
connection (management communication channel MCC).
It must be ensured that the optical network interface can be managed
in a standardized way to enable interoperable solutions between
different optical interface vendors and vendors of the optical
network management application. [RFC3591] defines managed objects
for the optical interface type but needs further extension to cover
the optical parameters required by this framework document.
Is to be noted that the CL (client device) and the DWDM network are
belonging to the same operator so the DWDM EMS and the Client devices
are connected to the same DCN and the communication security
considerations are applicable to CL as per DWDM devices.
Note that a software update of the optical interface components of
the client nodes must not lead obligatory to an update of the
software of the EMS and vice versa.
4.1.2. Indirect Connection to the DWDM Management System (First Optical
Node)
Kunze, et al. Expires January 25, 2020 [Page 11]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
An alternative as shown in Figure 4 should be used in cases where a
more integrated relationship between transport node (e.g. OM or OD
or ROADM) and client device is aspired. In that case a combination
of control plane features and manual management will be used.
+-----+
| NMS |
|_____|
/_____/
|
|
+---+---+
| EMS |
| |
+-------+
| MI SNMP or NETCONF/RESTCONF
|
LMP +------+-----------------------+
+------------+---+ +| + |
| | | |\ /| |
+---+--+ | +-+ \ |\ / | | +------+
| CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL |
| |-/C------+--- -| |----- /|-----| |----+-------/C-| |
+------+ | | / \| \ | | +------+
| |/ \| |
| + + |
+------------------------------+
CL = Client Device
/C = Single Channel optical Interface
OM = Optical Mux
OD = Optical Demux
EMS= Element Management System
MI= Management Interface
Figure 4: Direct connection between peer node and first optical
network node
For information exchange between the client node and the direct
connected node of the optical transport network LMP as specified in
RFC 4209 [RFC4209] should be used. This extension of LMP may be used
between a peer node and an adjacent optical network node as depicted
in Figure 4.
At the time of writing this document, LMP does not yet support the
transmission of configuration data (information). This functionality
is addressed by draft-ietf-ccamp-dwdm-if-lmp extending the RFC 4209
[RFC4209]. The use of LMP assumes that some form of a control
Kunze, et al. Expires January 25, 2020 [Page 12]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
channel exists between the client node and the WDM equipment. This
may be a dedicated lambda or an Ethernet Link.
4.2. Control Plane Considerations
The concept of integrated single channel DWDM interfaces equally
applies to management and control plane mechanisms. GMPLS control
plane protocols have been extended for WSON, e.g. RFC 7689 [RFC7689]
) for fixed grid signal and for flexi-grid RFC 7792 [RFC7792] ). One
important aspect of the Black Link [ITU-T.G.698.2] is the fact that
it is specific to the wavelength that is supported by the given link.
Therefore, the link can logically be considered as a fiber that is
transparent only for a single wavelength. In other words, the
wavelength becomes a characteristic of the link itself.
Nevertheless the procedure to light up the fiber may vary depending
on the implementation. Since the implementation is unknown a priori,
different sequences to light up a wavelength need to be considered:
1. Interface first, interface tuning: The transmitter is switched on
and the link is immediately transparent to its wavelength. This
requires the transmitter to carefully tune power and frequency
not overload the line system or to create transients.
2. Interface first, Optical Line System (OLS) tuning: The
transmitter is switched on first and can immediately go to the
max power allowed since the OLS performs the power tuning. This
leads to an intermediate state where the receiver does not
receive a valid signal while the transmitter is sending out one.
Alarm suppression mechanisms shall be employed to overcome that
condition.
3. OLS first, interface tuning: At first the OLS is tuned to be
transparent for a given wavelength, then transponders need to be
tuned up. Since the OLS in general requires the presence of a
wavelength to fine-tune its internal facilities there may be a
period where a valid signal is transmitted but the receiver is
unable to detect it. This equally need to be covered by alarm
suppression mechanisms.
4. OLS first, OLS tuning: The OLS is programmed to be transparent
for a given wavelength, then the interfaces need to be switched
on and further power tuning takes place. The sequencing of
enabling the link needs to be covered as well.
The preferred way to address these in a Control Plane enabled network
is neighbour discovery including exchange of link characteristics and
link property correlation. The general mechanisms are covered in RFC
Kunze, et al. Expires January 25, 2020 [Page 13]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
4209 [RFC4209] and RFC 4204 [RFC4204] which provides the necessary
protocol framework to exchange those characteristics between client
and Black Link. LMP-WDM is not intended for exchanging routing or
signaling information nor to provision the lambda in the transceiver
but covers:
1. Control channel management
2. Link property correlation
3. Link verification
4. Fault management
Extensions to LMP covering the parameter sets (e.g. application
codes) are needed, see draft-ietf-ccamp-dwdm-if-lmp. Additionally,
when client and server side are managed by different operational
entities, the link state may be useful to help the management system
to do troubleshooting or alarm correlation.
4.2.1. Considerations Using GMPLS Signaling
The deployment of single channel optical interfaces is leading to
some functional changes related to the control plane models and has
therefore some impact on the existing interfaces especially in the
case of a model where the edge node requests resources from the core
node and the edge node do not participate in the routing protocol
instance that runs among the core nodes. RFC 4208 [RFC4208] defines
the GMPLS UNI that can be used between edge and core node. In case
of integrated interfaces deployment additional functionalities are
needed to setup a connection.
It is necessary to differentiate between topology/signalling
information and configuration parameters that are needed to setup a
wavelength path. Using RSVP-TE could be used for the signalling and
the reservation of the wavelength path. But there are additional
information needed before RSVP-TE can start the signalling process.
There are three possibilities to proceed:
a. Using RSVP-TE only for the signalling and LMP as described above
to exchange information on the configured optical interface
within the edge node
b. RSVP-TE (typically with loose ERO) to transport additional
information
Kunze, et al. Expires January 25, 2020 [Page 14]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
c. Leaking IGP information instead of exchanging this information
needed from the optical network to the edge node (UNI will be
transformed to a border-peer model, see RFC 5146 [RFC5146] )
Furthermore following issues should be addressed:
a) The transceivers of peering edge nodes must be compatible. For
example, it may be required to know about FEC, modulation scheme, The
modulation format, the baudrate and many other parameters described
in the drafts reported in the Annex. Depending on where the
information is available, compatibility check may either happen
before signaling, when the signaling reaches the optical network
(e.g. at path computation time), or in the tail end node. An
extended version of LMP is needed to exchange this information in
case a. above, and to RSVP-TE as well in b. It would be helpful to
define some common profiles that will be supported (e.g. the
"application identifier") to summarize interface capabilities: if
both profiles match, signaling can succeed and provisioning be
achieved.
b) Due to the bidirectional wavelength path that must be setup, the
upstream edge node must include a wavelength value into the RSVP-TE
Path message. But in the case of a UNI model the client device may
not have full information about which wavelength must/should be
selected, whereas this information must be exchanged between the edge
and the core node. The special value defined in
[Network-Assigned-Upstream-Label] allows the optical network to
assign the actual wavelength to be used by the upstream transponder,
which is a simple and efficient solution to this issue.
5. Requirements
As network architectures become more complex, management and
operations, including the the provisioning process, need progress
towards automation. Simplifying and automating the entire management
as well as the network provisioning process while enabling higher
link utilization and faster restoration times are the main targets of
this section.
Supporting network management protocols such as NETCONF [RFC6241] or
RESTCONF [RFC8040] is the base for the communication among EMS/NMS,
centralized controller and network elements. This implies to speficy
the corresponding IETF YANG modules to fully and consistently manage
the feature discussed on this document.
Data plane interoperability as defined for example in [ITU-T.G.698.2]
is a precondition to take full benefit from standardized interfaces
between network and control/management plane.
Kunze, et al. Expires January 25, 2020 [Page 15]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
The following requirements are focusing on the usage of DWDM
interfaces using IETF technologies. Obvisouly, a common set of
solutions must be consistently supported by both the devices hosting
DWDM interfaces and the WDM network (i.e., the WDM line). The
solutions addressing the following requirements will be discussed in
further documents.
1 A YANG data model MUST define the optical parameters to be
exchanged (e.g., power setting) between the network elements and
the management plane so as to configure single channel interfaces
through NETCONF/RESTCONF.
2 LMP MUST allow to convey the relevant optical parameters between
two nodes to correlate neighbor characteristics and identify
common capabilities or compatible ranges between the WDM line and
single channel interfaces.
3 RSVP-TE MUST support the relevant parameters to be exchanged
between the device hosting the DWDM interface and the optical node
(e.g. the label value),
without preventing the network to remain in charge of the optical
path computation.
4 Power monitoring functions at both ends of the DWDM connection
MAY be used to further automate the setup and shutdown process of
the optical interfaces. LMP SHOULD suppport a way to carry
associated measurement from the client devices to the edges of the
WDM network.
5 In fault cases, the network SHOULD be able to recover wavelengths.
RSVP-TE extensions MUST remain compatible with [RFC4873] features.
The Yang modules should mimic a similar level of capability.
6. Gap Analysis
To enable a centralized control function, several gaps in existing
RFCs have been identified:
Kunze, et al. Expires January 25, 2020 [Page 16]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
1 RFC 8343 defines a generic YANG model for interface management.
However, to control DWDM interfaces, an augmentation needs to be
defined which allows to configure DWDM specifics such as wavelength
or FEC-type.
2 RFC 7224 defines iana-if-type YANG modules and needs extension to
include DWDM interfaces.
3 RFC 4204 defines the Link Management Protocol (LMP) to correlate
link properties between two adjacent nodes. Extensions are required
to cover the use cases described such as the correlation between a
Transponder and a ROADM node.
4 RFC 8454 defines an information model for Abstraction and
Control of TE Networks (ACTN). However it does not support
impairment aware path selection or computation.
5 RFC 7823 describes Performance-Based Path Selection for Explicitly
Routed Label Switched Paths (LSPs) Using TE Metric Extensions,
but does not define Metric extensions suitable for Impairment
aware routing in optical transport Networks
6 RFC 7471 in turn defines OSPF Traffic Engineering (TE) Metric
Extensions covering several use cases but lacks Imairment
awareness.
7 RFC 6163 provides a Framework for GMPLS and Path Computation
Element (PCE) Control of Wavelength Switched Optical Networks
(WSONs). While it describes methods for communicating RWA relevant
information, it does not identify such information.
8 Yang Models describing the optical parameter to be used to control
the network ad allow an external controller (like ACTN) to are
missing although are defined by ITU and reported in the
As this framework is focusing on the single operator use case, the
security concerns can be relaxed to a subset compared to a setup
where information is exchanged between external parties and over
external interfaces.
Concerning the access control to Management interfaces, security
issues can be generally addressed by authentication techniques
providing origin verification, integrity and confidentiality.
Additionally, access to Management interfaces can be physically or
logically isolated, by configuring them to be only accessible out-of-
band, through a system that is physically or logically separated from
the rest of the network infrastructure. In case where management
Kunze, et al. Expires January 25, 2020 [Page 17]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
interfaces are accessible in-band at the client device or within the
optical transport network domain, filtering or firewalling techniques
can be used to restrict unauthorized in-band traffic. Authentication
techniques may be additionally used in all cases.
7. Contributors
Arnold Mattheus
Deutsche Telekom
Darmstadt
Germany
email arnold.Mattheus@telekom.de
Manuel Paul
Deutsche Telekom
Berlin
Germany
email Manuel.Paul@telekom.de
Josef Roese
Deutsche Telekom
Darmstadt
Germany
email j.roese@telekom.de
Frank Luennemann
Deutsche Telekom
Muenster
Germany
email Frank.Luennemann@telekom.de
Dharini Hiremagalur
Juniper
1133 Innovation Way
Sunnyvale - 94089 California
USA
dharinih@juniper.net
8. References
8.1. Normative References
[ITU-T.G.694.1]
International Telecommunications Union, "Spectral grids
for WDM applications: DWDM frequency grid",
ITU-T Recommendation G.694.1, Febriary 2012.
Kunze, et al. Expires January 25, 2020 [Page 18]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
[ITU-T.G.698.2]
International Telecommunications Union, "Amplified
multichannel dense wavelength division multiplexing
applications with single channel optical interfaces",
ITU-T Recommendation G.698.2, November 2009.
[ITU-T.G.805]
International Telecommunications Union, "Spectral grids
for WDM applications: DWDM frequency grid",
ITU-T Recommendation G.805, March 2000.
[ITU-T.G.872]
International Telecommunications Union, "Architecture of
optical transport networks", ITU-T Recommendation G.872,
November 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of
Managed Objects for the Optical Interface Type", RFC 3591,
DOI 10.17487/RFC3591, September 2003,
<https://www.rfc-editor.org/info/rfc3591>.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
DOI 10.17487/RFC4204, October 2005,
<https://www.rfc-editor.org/info/rfc4204>.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, DOI 10.17487/RFC4208, October 2005,
<https://www.rfc-editor.org/info/rfc4208>.
[RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management
Protocol (LMP) for Dense Wavelength Division Multiplexing
(DWDM) Optical Line Systems", RFC 4209,
DOI 10.17487/RFC4209, October 2005,
<https://www.rfc-editor.org/info/rfc4209>.
[RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G.,
and H. Harai, "Signaling Extensions for Wavelength
Switched Optical Networks", RFC 7689,
DOI 10.17487/RFC7689, November 2015,
<https://www.rfc-editor.org/info/rfc7689>.
Kunze, et al. Expires January 25, 2020 [Page 19]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
[RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O.,
and D. Ceccarelli, "RSVP-TE Signaling Extensions in
Support of Flexi-Grid Dense Wavelength Division
Multiplexing (DWDM) Networks", RFC 7792,
DOI 10.17487/RFC7792, March 2016,
<https://www.rfc-editor.org/info/rfc7792>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[ITU-T.G.691]
ITU-T, "Optical interfaces for single channel STM-64 and
other SDH systems with optical amplifiers",
ITU-T Recommendation ITU-T G.691, 2008.
[ITU-T.G.693]
ITU-T, "Optical interfaces for intra-office systems",
ITU-T Recommendation ITU-T G.693, 2009.
[ITU-T.G.8081]
ITU-T, "Terms and definitions for Automatically Switched
Optical Networks (ASON)", ITU-T Recommendation G.8081",
ITU-T Recommendation ITU-T G.8081, September 2010.
[ITU-T.G.957]
ITU-T, "Optical interfaces for equipments and systems
relating to the synchronous digital hierarchy",
ITU-T Recommendation ITU-T G.957, 2006.
[Network-Assigned-Upstream-Label]
Internet Engineering Task Force, "Generalized Multi-
Protocol Label Switching (GMPLS) Resource reSerVation
Protocol with Traffic Engineering (RSVP- TE) mechanism
that enables the network to assign an upstream label for a
bidirectional LSP", draft-ietf-teas-network-assigned-
upstream-label draft-ietf-teas-network-assigned-upstream-
label, June 2017.
[RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support
Operation of MPLS-TE over GMPLS Networks", RFC 5146,
DOI 10.17487/RFC5146, March 2008,
<https://www.rfc-editor.org/info/rfc5146>.
Kunze, et al. Expires January 25, 2020 [Page 20]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
Appendix A. Use Cases
A comparison with the traditional operation scenarios provides an
insight of similarities and distinctions in operation and management
of DWDM interfaces. The following use cases provide an overview
about operation and maintenance processes.
A.1. Optical interface parameter collection
It is necessary to identify the Optical interface characteristics and
setting in order to properly calculate the ent to end path and match
the Head End interface against the Tail End interface compatibility.
The optical parameters may have multiple possible values that the
Controller (SDN or GMPLS) can use and select for the best network
optimisation.
A.2. DWDM client - ROADM interconection discovery
Being the the DWDM port and ROADM port belonging to different domains
and Network Elements, the interconnection between them is not
embedded in the Optical Nodes and can not be shared to the EMS and
the Controller. The Controller needs then to retrieve the
connectivity using data coming from the two domains correlating them
to discover the relationship. The methods to discover the
interconnection can be LMP, LLDP, installation provisioning or any
other mechanism checking using the light transmitted by the DWDM
transmitter and detecter by the ROAMD port photodiode. This use case
is fundamental to build the interconnections between the DWDM and
Client layer (e.g. Routers) and calculate the multilayer network
topology.
A.3. Service Setup
It is necessary to differentiate between different operational issues
for setting up a light path (a DWDM connection is specific in having
defined maximum impairments) within an operational network.
The first step is to determine if transceivers located at different
end-points are interoperable, i.e. support a common set of
operational parameters. In this step it is required to determine
transceiver capabilities in a way to be able to correlate them for
interoperability purposes. Such parameters include modulation
scheme, modulation parameters, FEC to name a few. If both
transceivers are controlled by the same NMS or CP, such data is
readily available. However in cases like Figure 4, a protocol needs
to be used to inform the controlling instance (NMS or CP) about
transceiver parameters. It is suggested to extend LMP for that
purpose.
Kunze, et al. Expires January 25, 2020 [Page 21]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
The second step is to determine the feasibility of a lightpath
between two transceivers without applying an optical signal.
Understanding the limitations of the transceiver pair, a path through
the optical network has to be found, whereby each path has an
individual set of impairments deteriorating a wavelength traveling
along that path. Since a single transceiver can support multiple
parameter sets, the selection of a path may limit the permissible
parameter sets determined in previous steps.
The third step is then to setup the connection itself and to
determine the Wavelength. This is done using the NMS of the optical
transport network or by means of a control plane interaction such as
signaling and includes the path information as well as the parameter
set information necessary to enable communication.
In a fourth step, optical monitoring is activated in the WDM network
in order to monitor the status of the connection. The monitor
functions of the optical interfaces at the terminals are also
activated in order to monitor the end to end connection.
Furthermore it should be possible to automate this step. After
connecting the client device to the neighbor control plane-enabled
transport node, a control adjacency may be automatically established,
e.g. using LMP.
A.4. Link Monitoring Use Cases
The use cases described below are assuming that power monitoring
functions are available in the ingress and egress network element of
the DWDM network, respectively. By performing link property
correlation it would be beneficial to include the current transmit
power value at reference point Ss and the current received power
value at reference point Rs. For example if the Client transmitter
power has a value of 0dBm and the ROADM interface measured power is
-6dBm the fiber patch cord connecting the two nodes may be pinched or
the connectors are dirty. As discussed before, the actual path or
selection of a specific wavelength within the allowed set is outside
the scope of LMP. The computing entities (e.g. the first optical
node originating the circuit) can rely on GMPLS IGP (OSPF) to
retrieve all the information related to the network, calculate the
path to reach the endpoint and signal the path implementation through
the network via RSVP-TE.
[ITU-T.G.698.2] defines a single channel optical interface for DWDM
systems that allows interconnecting network-external optical
transponders across a DWDM network. The optical transponders are
external to the DWDM network. This so-called 'Black Link' approach
illustrated in Fig. 5-1 of [ITU-T.G.698.2] and a copy of this figure
Kunze, et al. Expires January 25, 2020 [Page 22]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
is provided below in Figure 5. The single channel fiber link between
the Ss/Rs reference points and the ingress/egress port of the network
element on the domain boundary of the DWDM network (DWDM border NE)
is called access link. Based on the definition in [ITU-T.G.698.2] it
is part of the DWDM network. The access link is typically realized
as a passive fiber link that has a specific optical attenuation
(insertion loss). As the access link is an integral part of the DWDM
network, it is desirable to monitor its attenuation. Therefore, it
is useful to detect an increase of the access link attenuation, for
example, when the access link fiber has been disconnected and
reconnected (maintenance) and a bad patch panel connection
(connector) resulted in a significantly higher access link
attenuation (loss of signal in the extreme case of an open connector
or a fiber cut). In the following section, two use cases are
presented and discussed:
1) pure access link monitoring
2) access link monitoring with a power control loop
These use cases require a power monitor as described in G.697 (see
section 6.1.2), that is capable to measure the optical power of the
incoming or outgoing single channel signal. The use case where a
power control loop is in place could even be used to compensate an
increased attenuation if the optical transmitter can still be
operated within its output power range defined by its application
code.
Kunze, et al. Expires January 25, 2020 [Page 23]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
Use case 1: Access Link monitoring
+--------------------------+
| P(in) = P(Tx) - a(Tx) |
| ___ |
+----------+ | \ / Power Monitor |
| | P(Tx) | V P(in) |
| +----+ | Ss //\\ | | |\ |
| | TX |----|-----\\//------------------->| \ |
| +----+ | Access Link (AL-T) | . | | |
| | attenuation a(Tx) | . | |==============>
| | | . | | |
| External | | --->| / |
| Optical | | |/ |
|Transpond.| | P(out) |
| | | ___ |
| | | \ / Power Monitor |
| | P(Rx) | V P(out) |
| +----+ | Rs //\\ | | |\ |
| | RX |<---|-----\\//--------------------| \ |
| +----+ | Access Link (AL-R) | . | | |
| | Attenuation a(Rx) | . | |<==============
+----------+ | . | | |
| <---| / |
P(Rx) = P(out) - a(Rx) | |/ |
| |
| ROADM |
+--------------------------+
- For AL-T monitoring: P(Tx) and a(Tx) must be known
- For AL-R monitoring: P(RX) and a(Rx) must be known
An alarm shall be raised if P(in) or P(Rx) drops below a
configured threshold (t [dB]):
- P(in) < P(Tx) - a(Tx) - t (Tx direction)
- P(Rx) < P(out) - a(Rx) - t (Rx direction)
- a(Tx) =| a(Rx)
Alarms and events can be shared between Client and Network
via LMP.
Figure 5: Access Link Power Monitoring
Kunze, et al. Expires January 25, 2020 [Page 24]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
A.4.1. Pure Access Link (AL) Monitoring Use Case
Figure 6 illustrates the access link monitoring use case and the
different physical properties involved that are defined below:
- Ss, Rs: Single Channel reference points
- P(Tx): current optical output power of transmitter Tx
- a(Tx): access link attenuation in Tx direction (external
transponder point of view)
- P(in): measured current optical input power at the input port
of border DWDM NE
- t: user defined threshold (tolerance)
- P(out): measured current optical output power at the output port
of border DWDM NE
- a(Rx): access link attenuation in Rx direction (external
transponder point of view)
- P(Rx): current optical input power of receiver Rx
Description:
- The access link attenuation in both directions (a(Tx), a(Rx))
is known or can be determined as part of the commissioning
process. Typically, both values are very similar.
- A threshold value t has been configured by the operator. This
should also be done during commissioning.
- A control plane protocol is in place that allows
to periodically send the optical power values P(Tx) and P(Rx)
to the control plane protocol instance on the DWDM border NE.
This is illustrated in Figure 3.
- The DWDM border NE is capable to periodically measure the optical
power P(in) and P(out) as defined in G.697 by power monitoring
points depicted as triangles in the figures below.
Access Link monitoring process:
- Tx direction: the measured optical input power P(in) is compared
with the expected optical input power P(Tx) - a(Tx). If the
measured optical input power P(in) drops below the value
(P(Tx) - a(Tx) - t) a low power alarm shall be raised indicating
that the access link attenuation has exceeded a(Tx) + t.
- Rx direction: the measured optical input power P(Rx) is
compared with the expected optical input power P(out) - a(Rx).
If the measured optical input power P(Rx) drops below the value
(P(out) - a(Rx) - t) a low power alarm shall be raised indicating
that the access link attenuation has exceeded a(Rx) + t.
- to avoid toggling errors, the low power alarm threshold shall be
lower than the alarm clear threshold.
Kunze, et al. Expires January 25, 2020 [Page 25]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
Use case 2: Access Link monitoring through LMP
+----------+ +--------------------------+
| +------+ | P(Tx), P(Rx) | +-------+ |
| | | | =================> | | | |
| | LMP | | P(in), P(out) | | LMP | |
| | Agent| | <================= | | Agent | |
| +------+ | | +-------+ |
| | | |
| | | P(in) - P(Tx) - a(Tx) |
| | | ___ |
| | | \ / Power Monitor |
| | P(Tx) | V |
| +----+ | Ss //\\ | | |\ |
| | TX |----|-----\\//------------------->| \ |
| +----+ | Access Link (AL-T) | . | | |
| | attenuation a(Tx) | . | |==============>
| | | . | | |
| External | | --->| / |
| Optical | | |/ |
|Transpond.| | P(out) |
| | | ___ |
| | | \ / Power Monitor |
| | P(Rx) | V |
| +----+ | Rs //\\ | | |\ |
| | RX |<---|-----\\//--------------------| \ |
| +----+ | Access Link (AL-R) | . | | |
| | Attenuation a(Rx) | . | |<==============
+----------+ | . | | |
| <---| / |
P(Rx) = P(out) - a(Rx) | |/ |
| |
| ROADM |
+--------------------------+
- For AL-T monitoring: P(Tx) and a(Tx) must be known
- For AL-R monitoring: P(RX) and a(Rx) must be known
An alarm shall be raised if P(in) or P(Rx) drops below a
configured threshold (t [dB]):
- P(in) < P(Tx) - a(Tx) - t (Tx direction)
- P(Rx) < P(out) - a(Rx) - t (Rx direction)
- a(Tx) = a(Rx)
Alarms and events can be shared between Client and Network
via LMP according to [RFC4204] and [RFC4209]
Kunze, et al. Expires January 25, 2020 [Page 26]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
Figure 6: Extended LMP Model
A.4.2. Power Control Loop Use Case
This use case is based on the access link monitoring as
described above. In addition, the border NE is running a power
control application that is capable to control the optical output
power of the single channel tributary signal at the output port
of the border DWDM NE (towards the external receiver Rx) and the
optical output power of the single channel tributary signal at
the external transmitter Tx within their known operating range.
The time scale of this control loop is typically relatively slow
(e.g. some 10s or minutes) because the access link attenuation
is not expected to vary much over time (the attenuation only
changes when re-cabling occurs).
From a data plane perspective, this use case does not require
additional data plane extensions. It does only require a protocol
extension in the control plane (e.g. this LMP draft) that allows
the power control application residing in the DWDM border NE to
modify the optical output power of the DWDM domain-external
transmitter Tx within the range of the currently used application
code. Figure 7 below illustrates this use case utilizing
LMP with the extensions identified in this document.
Kunze, et al. Expires January 25, 2020 [Page 27]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
Use case 3: Power Control Loop
+----------+ +--------------------------+
| +------+ |P(Tx),P(Rx),Set(P(out))| +-------+ +--------+ |
| | | | ====================> | | | | Power | |
| | LMP | | P(in),P(out),Set(PTx) | | LMP | |Control | |
| | | | <==================== | | | | Loop | |
| +------+ | | +-------+ +--------+ |
| | | | |
| +------+ | | P(in) = P(Tx) - a(Tx) |
| |C.Loop| | | ___ |
| +------+ | | \ / Power Monitor |
| | | P(Tx) | V |
| +------+ | Ss //\\ | | |\ |
| | TX |>----|-----\\//---------------------->| \ |
| +------+ | Access Link (AL-T) | . | | |
| VOA(Tx) | attenuation a(Tx) | . | |==============>
| | | . | | |
| External | | --->| / |
| Optical | | |/ |
|Transpond.| | P(out) |
| | | ___ |
| | | \ / Power Monitor |
| | P(Rx) | V |
| +----+ | Rs //\\ | | VOA(out) |\ |
| | RX |<---|-----\\//---------------------<|-------| \ |
| +----+ | Access Link (AL-R) | . | | |
| | attenuation a(Rx) | . | |<=======
+----------+ | VOA(out) | | |
| <--<|-------| / |
P(Rx) = P(out) - a(Rx) | |/ |
| |
| ROADM |
+--------------------------+
Figure 7: Power control loop
- The power control loop in transponders and ROADMs controls
the Variable Optical Attenuators (VOA) to adjust the proper
power in base of the ROADM and Receiver characteristics and
the Access Link attenuation
Kunze, et al. Expires January 25, 2020 [Page 28]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
A.5. Optical Circuit restoration
Upon an network failure (e.g. fiber cut) the Controller or GMPLS can
initiate an Optical Path restoration process. Other than reroute the
optical path the controller may need to retune the wavelength and
modify the DWDM Transceiver working parameters (e.g. FEC, Modulation
Format, etc.). This operation is done in realtime and can benefit of
Netconf/Yang interface or RSVP signallin on the UNI interface.
A.6. Multilayer restoration
A network failure can be due to an DWDM port failure. The Controller
is the only actor able to fix issue setting a new circuit terminated
on a good Client port (GMPLS is not able to make an new path choosing
a different end-point). Other than reroute the optical path the
controller may need to provision the wavelength and modify the DWDM
Transceiver working parameters (e.g. FEC, Modulation Format, etc.).
This operation is done in realtime and must be supported by Netconf/
Yang interface.
Appendix B. Detailed info drafts
In this section are reported some examples and references on the MIB,
Yang and LMP usage. The MIB and TLV defining the parameters
described above are reported in the drafts below and are intended as
informative data:
Kunze, et al. Expires January 25, 2020 [Page 29]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
draft-ietf-ccamp-dwdm-if-lmp
Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for
Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems
to manage the application code of optical interface parameters in
DWDM application
draft-ggalimbe-ccamp-flex-if-lmp
Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for
Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems
to manage the application code of optical interface parameters in
DWDM application
draft-ietf-ccamp-dwdm-if-param-yang
A YANG model to manage the optical interface parameters for an
external transponder in a WDM network
draft-ietf-ccamp-flexigrid-yang
YANG data model for Flexi-Grid Optical Networks
draft-ietf-ccamp-wson-iv-info
Information Model for Wavelength Switched Optical Networks (WSONs)
with Impairments Validation
draft-ietf-ccamp-wson-iv-encode
Information Encoding for WSON with Impairments Validation
draft-galimbe-ccamp-iv-yang
A YANG model to manage the optical parameters for in a WDM network
NOTE: the above information is defined at the time of publication of
this document and thus subject to change.
Authors' Addresses
Ruediger Kunze (editor)
Deutsche Telekom
Winterfeldtstr. 21-27
10781 Berlin
Germany
Phone: +491702275321
Email: RKunze@telekom.de
Kunze, et al. Expires January 25, 2020 [Page 30]
Internet-Draft draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13 July 2019
Gert Grammel (editor)
Juniper
Oskar-Schlemmer Str. 15
80807 Muenchen
Germany
Phone: +49 1725186386
Email: ggrammel@juniper.net
Dieter Beller
Nokia
Lorenzstrasse, 10
70435 Stuttgart
Germany
Phone: +4971182143125
Email: Dieter.Beller@nokia.com
Gabriele Galimberti (editor)
Cisco
Via S. Maria Molgora, 48c
20871 - Vimercate
Italy
Phone: +390392091462
Email: ggalimbe@cisco.com
Julien Meuric
Orange
2, Avenue Pierre Marzin
22307 Lannion Cedex
France
Phone: +33
Email: julien.meuric@orange.com
Kunze, et al. Expires January 25, 2020 [Page 31]
