draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-07.txt   draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-08.txt 
Internet Engineering Task Force R. Kunze, Ed. Internet Engineering Task Force R. Kunze, Ed.
Internet-Draft Deutsche Telekom Internet-Draft Deutsche Telekom
Intended status: Informational G. Grammel, Ed. Intended status: Informational G. Grammel, Ed.
Expires: March 8, 2018 Juniper Expires: June 16, 2018 Juniper
D. Beller D. Beller
Nokia Nokia
G. Galimberti, Ed. G. Galimberti, Ed.
Cisco Cisco
J. Meuric J. Meuric
France Telecom Orange Orange
September 4, 2017 December 13, 2017
A framework for Management and Control of DWDM optical interface A framework for Management and Control of DWDM optical interface
parameters parameters
draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-07 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-08
Abstract Abstract
To ensure an efficient data transport, meeting the requirements The control and management of DWDM interfaces are a precondition for
requested by today's IP-services the control and management of DWDM enhanced multilayer networking. They are needed to ensure an
interfaces are a precondition for enhanced multilayer networking and efficient data transport, to meet the requirements requested by
for a further automation of network provisioning and operation. This today's IP-services and to provide a further automation of network
document describes use cases, requirements and solutions for the provisioning and operations. This document describes use cases,
control and management of optical interfaces parameters according to requirements and solutions for the control and management of optical
different types of single channel DWDM interfaces. The focus is on interface parameters according to different types of single channel
automating the network provisioning process irrespective on how it is DWDM interfaces. The focus is on automating the network provisioning
triggered i.e. by EMS, NMS or GMPLS. This document covers management process irrespective on how it is triggered i.e. by EMS, NMS or
as well as control plane considerations in different management cases GMPLS. This document covers management and control considerations in
of single channel DWDM interfaces. The purpose is to identify the different scenarios of single channel DWDM interfaces. The purpose
necessary information elements and processes to be used by control or is to identify the necessary information and processes to be used by
management systems for further processing. control or management systems to properly and efficiently drive the
network.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 8, 2018. This Internet-Draft will expire on June 16, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4
3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Comparison of approaches for transverse compatibility . . 5 3.1. Comparison of Approaches for Transverse Compatibility . . 5
3.1.1. Multivendor DWDM line system with transponders . . . 5 3.1.1. Multivendor DWDM Line System with Transponders . . . 5
3.1.2. Integrated single channel DWDM deployments on the 3.1.2. Integrated Single Channel DWDM Deployments on the
client site . . . . . . . . . . . . . . . . . . . . . 6 Client Site . . . . . . . . . . . . . . . . . . . . . 7
4. Solutions for managing and controlling single channel optical 4. Solutions for Managing and Controlling Single Channel Optical
interface . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Separate Operation and Management Approaches . . . . . . 9 4.1. Separate Operation and Management Approaches . . . . . . 10
4.1.1. Direct connection to the management system . . . . . 9 4.1.1. Direct Connection to the Management System . . . . . 10
4.1.2. Indirect connection to the DWDM management system 4.1.2. Indirect Connection to the DWDM Management System
(first optical node) . . . . . . . . . . . . . . . . 10 (First Optical Node) . . . . . . . . . . . . . . . . 11
4.2. Control Plane Considerations . . . . . . . . . . . . . . 12 4.2. Control Plane Considerations . . . . . . . . . . . . . . 13
4.2.1. Considerations using GMPLS signaling . . . . . . . . 13 4.2.1. Considerations Using GMPLS Signaling . . . . . . . . 14
5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Link monitoring Use Cases . . . . . . . . . . . . . . . . 15 5.2. Link Monitoring Use Cases . . . . . . . . . . . . . . . . 16
5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 18 5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 19
5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 20 5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 21
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The usage of the single channel DWDM interfaces (e.g. in routers) The usage of external single channel DWDM interfaces (e.g. in
connected to a DWDM Network (which include ROADMs and optical routers) connected to a DWDM Network (e.g. router connected to a
amplifiers) adds a further networking option for operators allowing network of ROADMs and optical amplifiers) adds a further networking
new scenarios but require harmonised control and management plane option for operators but requires an harmonised control and
interaction between different network domains. management plane interaction between the different network domains.
Carriers deploy their networks today based on transport and packet Carriers deploy their networks today based on transport and packet
network infrastructures as domains to ensure high availability and a network infrastructures as domains to ensure high availability and a
high level of redundancy. Both network domains were operated and high level of redundancy combining the Packet and Transport
managed separately. This is the status quo in many carrier networks restoration. Both network domains were operated and managed
today. In the case of deployments, where the optical transport separately. This is the status quo in many carrier networks today.
interface moves into the client device (e.g. router) an interaction In the case of deployments where the optical transport interface
between those domains becomes necessary. 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 This framework specifies different levels of control and management
plane interaction to support the usage of single channel optical plane interaction to support the usage of single channel optical
interfaces in carrier networks in an efficient manner. interfaces in carrier networks in an efficient manner. The
interfaces between the two layers can be wither gray or coloured.
The objective of this document is to provide a framework for the
control and management of transceiver interfaces based on the
corresponding use cases and requirements to ensure an efficient and
optimized data transport.
Although Optical routing and wavelength assignment based on WSON is Although Optical routing and wavelength assignment based on WSON is
out of scope, they can benefit from the optical parameters that are out of scope, they can benefit from the optical parameters that are
exchanged between the Client and the DWDM Network. Also, the exchanged between the Client and the DWDM Network. Also, the
wavelength ordering process and the process how to determine the wavelength ordering process and determining the demand for a new
demand for a new wavelength path through the network is out of scope. wavelength path through the network are out of scope.
Note that the Control and Management Planes are two separate entities Note that the Control and Management Planes are two separate entities
that are handling the same information in different ways. that may handle the same information in different ways.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
While [RFC2119] describes 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 2. Terminology and Definitions
The current generation of WDM netwoks are single vendor networks The current generation of WDM netwoks are single vendor networks
where the optical line system and the transponders are tightly where the optical line system and the transponders are tightly
integrated. The DWDM interface migration from the transponders to integrated. The DWDM interface migration from integrated
the colored interfaces change this scenario, by introducing a transponders to third party transponders or colored interfaces change
standardized interface at the level of OCh between the DWDM interface this scenario and introduces a standardized interface at the level of
and the DWDM network. OCh between the DWDM interface and the DWDM network.
Black Link: The Black Link [ITU.G698.2] allows supporting an optical Black Link: The Black Link [ITU.G698.2] allows supporting an optical
transmitter/receiver pair of a single vendor or from different transmitter/receiver pair (of a single vendor or from different
vendors to provide a single optical channel interface and transport vendors) to provide a single optical channel interface and transport
it over an optical network composed of amplifiers, filters, add-drop it over an optical network composed of amplifiers, filters, add-drop
multiplexers which may be from a different vendor. Therefore the multiplexers these being possibly from different vendors. Therefore
standard defines the ingress and egress parameters for the optical the standard defines the ingress and egress parameters for the
interfaces at the reference points Ss and Rs. optical interfaces at the reference points Ss and Rs.
Single Channel DWDM Interface: The single channel interfaces to DWDM Single Channel DWDM Interface: The single channel interfaces to DWDM
systems defined in G.698.2, which currently include the following systems defined in G.698.2, which currently include the following
features: channel frequency spacing: 50 GHz and wider (defined in features: channel frequency spacing: 50 GHz and wider (defined in
[ITU-T G.694.1]); bit rate of single channel: Up to 10 Gbit/s. [ITU-T G.694.1]); bit rate of single channel: Up to 10 Gbit/s.
Future revisions are expected to include application codes for bit Future revisions are expected to include application codes for bit
rates up to 40 Gb/s. rates up to 40 Gb/s.
Forward error correction (FEC): FEC is a way of improving the Forward Error Correction (FEC): FEC is a way of improving the
performance of high-capacity optical transmission systems. Employing performance of high-capacity optical transmission systems. Employing
FEC in optical transmission systems yields system designs that can FEC in optical transmission systems yields system designs that can
accept relatively large BER (much more than 10-12) in the optical accept relatively large BER (much more than 10^-12) in the optical
transmission line (before decoding). transmission line (before decoding).
Administrative domain [G.805]: the extent of resources which belong Administrative domain [G.805]: the extent of resources which belong
to a single player such as a network operator, a service provider or to a single player such as a network operator, a service provider or
an end-user. Administrative domains of different players do not an end-user. Administrative domains of different players do not
overlap amongst themselves. overlap amongst themselves.
Intra-domain interface (IaDI) [G.872]: A physical interface within an Intra-domain interface (IaDI) [G.872]: A physical interface within an
administrative domain. administrative domain.
skipping to change at page 4, line 47 skipping to change at page 5, line 5
represents the boundary between two administrative domains. represents the boundary between two administrative domains.
Management Plane [G.8081]: The management plane performs management Management Plane [G.8081]: The management plane performs management
functions for the transport plane, the control plane and the system functions for the transport plane, the control plane and the system
as a whole. It also provides coordination between all the planes. as a whole. It also provides coordination between all the planes.
The following management functional areas are performed in the The following management functional areas are performed in the
management plane: performance management, fault management, management plane: performance management, fault management,
configuration management, accounting management and security configuration management, accounting management and security
management. management.
Control Plane[G.8081]: The control plane performs neighbour Control Plane [G.8081]: Through signaling, the control plane sets up
discovery, call control and connection control functions. Through and releases connections, may restore a connection in case of a
signalling, the control plane sets up and releases connections, and failure, and also performs other functions (e.g., neighbor discovery,
may restore a connection in case of a failure. The control plane topology distribution) in support of those.
also performs other functions in support of call and connection
control, such as neighbour discovery and routing information
dissemination.
Transponder: A Transponder is a network element that performs O/E/O Transponder: A Transponder is a network element that performs O/E/O
(Optical /Electrical/Optical) conversion. In this document it is (Optical /Electrical/Optical) conversion. In this document it is
referred only transponders with 3R (rather than 2R or 1R referred only transponders with 3R (rather than 2R or 1R
regeneration) as defined in [ITU.G.872]. regeneration) as defined in [ITU.G.872].
Line System: A Line System is a portion of the network including Add
Drop Multiplexers (ROADM) Line Amplifiers and the the fibers
connecting them.
Client DWDM interface: A Transceiver element that performs E/O Client DWDM interface: A Transceiver element that performs E/O
(Electrical/Optical) conversion. In this document it is referred as (Electrical/Optical) conversion. In this document it is referred as
the DWDM side of a transponder as defined in [ITU.G.872]. the DWDM side of a transponder as defined in [ITU.G.872].
3. Solution Space 3. Solution Space
The solution space of this document is focusing on aspects related to The solution space of this document is focusing on aspects related to
the management and control of single-channel optical interface the management and control of single-channel optical interface
parameters of physical point-to-point and ring DWDM applications on parameters of physical point-to-point and ring DWDM applications on
single-mode optical fibres and allows the direct connection of a wide single-mode optical fibres and allows the direct connection of a wide
variety of equipment using a DWDM link, for example variety of equipment using a DWDM link, for example
1. A digital cross-connect with multiple optical interfaces, 1. A digital cross-connect with multiple optical interfaces,
supplied by a different vendor from the line system supplied by a different vendor from the line system
2. Devices as routing, switching or compute nodes, each from a 2. Devices as routing, switching or compute nodes, each from a
different vendor, providing optical line interfaces different vendor, providing optical line interfaces
3. A combination of the above 3. A combination of the above
3.1. Comparison of approaches for transverse compatibility 3.1. Comparison of Approaches for Transverse Compatibility
This section describes two ways to achieve transverse compatibility. This section describes two ways to achieve transverse compatibility.
Section 3.1.1 describes the classic model based on well defined Section 3.1.1 describes the classic model based on well defined
inter-domain interfaces. Section 3.1.2 defines a model ensuring inter-domain interfaces. Section 3.1.2 defines a model ensuring
interoperability on the line side of the optical network. interoperability on the line side of the optical network.
3.1.1. Multivendor DWDM line system with transponders 3.1.1. Multivendor DWDM Line System with Transponders
As illustrated in Figure 1, for this approach interoperability is As illustrated in Figure 1, for this approach interoperability is
achieved via the use of optical transponders providing OEO (allowing achieved via the use of optical transponders providing OEO (allowing
conversion to appropriate parameters). The optical interfaces can conversion to appropriate parameters). The optical interfaces can
then be any short reach standardized optical interface that both 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], vendors support, such as those found in [ITU-T G.957] [ITU-T G.691],
[ITU-T G.693], [ITU-T G.959.1], etc. [ITU-T G.693], [ITU-T G.959.1], etc.
IrDI IaDI IrDI IaDI
| | | |
skipping to change at page 6, line 34 skipping to change at page 6, line 36
Figure 1: Inter and Intra-Domain Interface Identification Figure 1: Inter and Intra-Domain Interface Identification
In the scenario of Figure 1 the administrative domain is defined by In the scenario of Figure 1 the administrative domain is defined by
the Interdomain Interface (IrDI). This interface terminates the DWDM the Interdomain Interface (IrDI). This interface terminates the DWDM
domain. The line side is characterized by the IaDI. This interface domain. The line side is characterized by the IaDI. This interface
specifies the internal parameter set of the optical administrative specifies the internal parameter set of the optical administrative
domain. In the case of a client DWDM interface deployment this domain. In the case of a client DWDM interface deployment this
interface moves into the client device and extends the optical and interface moves into the client device and extends the optical and
administrative domain towards the client node. ITU-T G.698.2 for administrative domain towards the client node. ITU-T G.698.2 for
example specifies the parameter set for a certain set of example specifies a set of parameter set for a certain set of
applications. applications.
This document elaborates only the IaDI Interface as shown in Figure 1 This document elaborates only the IaDI Interface as shown in Figure 1
as transversely compatible and multi-vendor interface within one as transversely compatible and multi-vendor interface within one
administrative domain controlled by the network operator. administrative domain controlled by the network operator.
SNMP/SMI, Yang models and LMP TLV to support the direct exchange of SNMP/SMI, Yang models and LMP TLV to support the direct exchange of
information between the client and the network management and control information between the client and the network management and control
plane will be specified in further documents. plane will be specified in further documents.
3.1.2. Integrated single channel DWDM deployments on the client site 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 In case of a deployment as shown in Figure 2, through the use of DWDM
interfaces, multi-vendor interconnection can also be achieved while interfaces, multi-vendor interconnection can also be achieved. Among
removing the need for one short reach transmitter and receiver pair the possible use cases, it may be used to remove the need for one
per channel (eliminating the transponders). short reach transmitter and receiver pair per channel (eliminating
the transponders).
Figure 2 shows a set of reference points, for single-channel Figure 2 shows a set of reference points, for single-channel
connection (Ss and Rs) between transmitters (Tx) and receivers (Rx). connection (Ss and Rs) between transmitters (Tx) and receivers (Rx).
Here the DWDM network elements include an optical multiplexer (OM) Here the DWDM network elements include an optical multiplexer (OM)
and an optical demultiplexer (OD) (which are used as a pair with the and an optical demultiplexer (OD) (which are used as a pair with the
peer element), one or more optical amplifiers and may also include peer element), one or more optical amplifiers and may also include
one or more OADMs. one or more OADMs.
|==================== Black Link =======================| |==================== Black Link =======================|
skipping to change at page 7, line 29 skipping to change at page 8, line 29
+---+ | | | | | | | | | | | | +---+ +---+ | | | | | | | | | | | | +---+
Tx L2---|->| OM |-|>|------|->| ROADM|--|------|->| OD |--|-->Rx L2 Tx L2---|->| OM |-|>|------|->| ROADM|--|------|->| OD |--|-->Rx L2
+---+ | | | | | | | | | | | | +---+ +---+ | | | | | | | | | | | | +---+
+---+ | | | | | +------+ | | | | | +---+ +---+ | | | | | +------+ | | | | | +---+
Tx L3---|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3 Tx L3---|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3
+---+ | | / | Link +----|--|----+ Link | \ | | +---+ +---+ | | / | Link +----|--|----+ Link | \ | | +---+
+-----------+ | | +----------+ +-----------+ | | +----------+
+--+ +--+ +--+ +--+
|==== Black Link ====| | | |==== Black Link ====| | |
v | v |
+---+ +---+ +-----+ +-----+
RxLx TxLx |RxLx | |TxLx |
+---+ +---+ +-----+ +-----+
Ss = Reference point at the DWDM network element tributary output Ss = Reference point at the DWDM network element tributary output
Rs = Reference point at the DWDM network element tributary input Rs = Reference point at the DWDM network element tributary input
Lx = Lambda x Lx = Lambda x
OM = Optical Mux OM = Optical Mux
OD = Optical Demux OD = Optical Demux
ROADM = Reconfigurable Optical Add Drop Mux ROADM = Reconfigurable Optical Add Drop Mux
Linear DWDM network as per ITU-T G.698.2 Linear DWDM network as per ITU-T G.698.2
skipping to change at page 8, line 9 skipping to change at page 9, line 9
The single administrative domain may consist of several vendor The single administrative domain may consist of several vendor
domains. Even in that case a common network management and control domains. Even in that case a common network management and control
is required to ensure a consistent operation and provisioning of the is required to ensure a consistent operation and provisioning of the
entire connection. entire connection.
SNMP/SMI, Yang models and LMP TLV to support the direct exchange of SNMP/SMI, Yang models and LMP TLV to support the direct exchange of
information between the client and the network management and control information between the client and the network management and control
plane will be specified in further documents. plane will be specified in further documents.
4. Solutions for managing and controlling single channel optical 4. Solutions for Managing and Controlling Single Channel Optical
interface Interface
Operation and management of WDM systems is traditionally seen as a Operation and management of WDM systems is traditionally seen as a
homogenous group of tasks that could be carried out best when a homogenous group of tasks that could be carried out best when a
single management system or an umbrella management system is used. single management system or a hierarchical management system is used.
Currently each WDM vendor provides an Element Management System (EMS) Currently each WDM vendor provides an Element Management System (EMS)
that also provisions the wavelengths. In a multi-vendor line system, that also provisions the wavelengths. In a multi-vendor line system,
such single-vendor EMS requirement is no more effective. New methods such single-vendor EMS requirement is no more effective. New methods
of managing and controlling line systems need to be looked at. of managing and controlling line systems need to be looked at.
Therefore from the operational point of view the following approaches Therefore from the operational point of view the following approaches
will be considered to manage and operate optical interfaces. will be considered to manage and operate optical interfaces.
1. Separate operation and management of client device and the 1. Separate operation and management of client device and the
transport network whereas the interface of the client belongs to transport network whereas the interface of the client belongs to
the administrative domain of the transport network and will be the administrative domain of the transport network and will be
managed by the transport group. This results in two different managed by the transport group. This results in two different
approaches to send information to the management system approaches to send information to the management system
a. Direct connection from the client to the management system, a. Direct connection from the client node to the transport
ensuring a management of the DWDM interface of the optical management system, ensuring a management of the DWDM interface of
network (e.g. EMS, NMS) the optical network (e.g. EMS, NMS)
b. Indirect connection to the management system of the optical b. Indirect connection to the management system of the optical
network using a protocol (LMP) between the client device and the network using a protocol (e.g. LMP) between the client device
directly connected WDM system node to exchange management and the directly connected WDM system node to exchange management
information with the optical domain information with the optical domain
2. Common operation and management of client device including the 2. Common operation and management of client device including the
single channel DWDM part and the Transport network single channel DWDM part and the Transport network
The first option keeps the status quo in large carrier networks as 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 mentioned above. In that case it must be ensured that the full FCAPS
Management (Fault, Configuration, Accounting, Performance and Management (Fault, Configuration, Accounting, Performance and
Security) capabilities are supported. This means from the management Security) capabilities are supported. This means from the management
staff point of view nothing changes. The transceiver/receiver staff point of view nothing changes. The transceiver/receiver
skipping to change at page 9, line 10 skipping to change at page 10, line 10
The second solution addresses the case where underlying WDM transport The second solution addresses the case where underlying WDM transport
network is mainly used to interconnect a homogeneous set of client network is mainly used to interconnect a homogeneous set of client
nodes (e.g. IP routers or digital crossconnects). Since the service nodes (e.g. IP routers or digital crossconnects). Since the service
creation and restoration could be done by the higher layers (e.g. creation and restoration could be done by the higher layers (e.g.
IP), this may lead to an efficient network operation and a higher IP), this may lead to an efficient network operation and a higher
level of integration. level of integration.
4.1. Separate Operation and Management Approaches 4.1. Separate Operation and Management Approaches
4.1.1. Direct connection to the management system 4.1.1. Direct Connection to the Management System
As depicted in Figure 3 (case 1a) one possibility to manage the As depicted in Figure 3 (case 1a) one possibility to manage the
optical interface within the client domain is a direct connection to optical interface within the client domain is a direct connection to
the management system of the optical domain. This ensures the management system of the optical domain. This ensures
manageability as usual. manageability as usual.
+-----+ +-----+
| NMS | | NMS |
|_____| |_____|
/_____/ /_____/
skipping to change at page 10, line 14 skipping to change at page 11, line 14
The exchange of management information between client device and the The exchange of management information between client device and the
management system assumes that some form of a direct management management system assumes that some form of a direct management
communication link exists between the client device and the DWDM communication link exists between the client device and the DWDM
management system (e.g. EMS). This may be an Ethernet Link or a DCN management system (e.g. EMS). This may be an Ethernet Link or a DCN
connection (management communication channel MCC). connection (management communication channel MCC).
It must be ensured that the optical network interface can be managed It must be ensured that the optical network interface can be managed
in a standardized way to enable interoperable solutions between in a standardized way to enable interoperable solutions between
different optical interface vendors and vendors of the optical different optical interface vendors and vendors of the optical
network management application. RFC 3591 [RFC3591] defines managed network management application. [RFC3591] defines managed objects
objects for the optical interface type but needs further extension to for the optical interface type but needs further extension to cover
cover the optical parameters required by this framework document. the optical parameters required by this framework document.
Therefore an extension to this MIB for the optical interface has been
drafted in [DWDM-interface-MIB]. SNMP is used to read parameters and
get notifications and alarms, netconf and yang models are needed to
easily provision the interface with the right parameter set as
described in [YANG]
Note that a software update of the optical interface components of Note that a software update of the optical interface components of
the client nodes must not lead obligatory to an update of the the client nodes must not lead obligatory to an update of the
software of the EMS and vice versa. software of the EMS and vice versa.
4.1.2. Indirect connection to the DWDM management system (first optical 4.1.2. Indirect Connection to the DWDM Management System (First Optical
node) Node)
An alternative as shown in Figure 4 can be used in cases where a more An alternative as shown in Figure 4 should be used in cases where a
integrated relationship between transport node (e.g. OM or OD or more integrated relationship between transport node (e.g. OM or OD
ROADM) and client device is aspired. In that case a combination of or ROADM) and client device is aspired. In that case a combination
control plane features and manual management will be used. of control plane features and manual management will be used.
+-----+ +-----+
| NMS | | NMS |
|_____| |_____|
/_____/ /_____/
| |
| |
+---+---+ +---+---+
| EMS | | EMS |
| | | |
skipping to change at page 11, line 45 skipping to change at page 12, line 45
OM = Optical Mux OM = Optical Mux
OD = Optical Demux OD = Optical Demux
EMS= Element Management System EMS= Element Management System
MI= Management Interface MI= Management Interface
Figure 4: Direct connection between peer node and first optical Figure 4: Direct connection between peer node and first optical
network node network node
For information exchange between the client node and the direct For information exchange between the client node and the direct
connected node of the optical transport network LMP as specified in connected node of the optical transport network LMP as specified in
RFC 4209 [RFC4209] should be used. This extension of LMP may be used [RFC4209] should be used. This extension of LMP may be used between
between a peer node and an adjacent optical network node as depicted a peer node and an adjacent optical network node as depicted in
in Figure 4. Figure 4.
The LMP based on RFC 4209 does not yet support the transmission of At the time of writing this document, LMP does not yet support the
configuration data (information). This functionality must be added transmission of configuration data (information). This functionality
to the existing extensions of the protocol. The use of LMP-WDM must be added to the protocol. The use of LMP assumes that some form
assumes that some form of a control channel exists between the client of a control channel exists between the client node and the WDM
node and the WDM equipment. This may be a dedicated lambda or an equipment. This may be a dedicated lambda or an Ethernet Link.
Ethernet Link.
4.2. Control Plane Considerations 4.2. Control Plane Considerations
The concept of integrated single channel DWDM interfaces equally The concept of integrated single channel DWDM interfaces equally
applies to management and control plane mechanisms. GMPLS control applies to management and control plane mechanisms. GMPLS control
plane protocols have been extended for WSON, e.g. [RFC7689] for plane protocols have been extended for WSON, e.g. [RFC7689] for
fixed grid signal and for flexi-grid [RFC7792]. One important aspect fixed grid signal and for flexi-grid [RFC7792]. One important aspect
of the [G.698.2] is the fact that it includes the wavelength that is of the Black Link [G.698.2] is the fact that it includes the
supported by the given link. Therefore, the link can logically be wavelength that is supported by the given link. Therefore, the link
considered as a fiber that is transparent only for a single can logically be considered as a fiber that is transparent only for a
wavelength. In other words, the wavelength becomes a characteristic single wavelength. In other words, the wavelength becomes a
of the link itself. characteristic of the link itself.
Nevertheless the procedure to light up the fiber may vary depending Nevertheless the procedure to light up the fiber may vary depending
on the implementation. Since the implementation is unknown a priori, on the implementation. Since the implementation is unknown a priori,
different sequences to light up a wavelength need to be considered: different sequences to light up a wavelength need to be considered:
1. Interface first, interface tuning: The transmitter is switched on 1. Interface first, interface tuning: The transmitter is switched on
and the link is immediately transparent to its wavelength. This and the link is immediately transparent to its wavelength. This
requires the transmitter to carefully tune power and frequency requires the transmitter to carefully tune power and frequency
not overload the line system or to create transients. not overload the line system or to create transients.
skipping to change at page 12, line 51 skipping to change at page 13, line 51
suppression mechanisms. suppression mechanisms.
4. OLS first, OLS tuning: The OLS is programmed to be transparent 4. OLS first, OLS tuning: The OLS is programmed to be transparent
for a given wavelength, then the interfaces need to be switched for a given wavelength, then the interfaces need to be switched
on and further power tuning takes place. The sequencing of on and further power tuning takes place. The sequencing of
enabling the link needs to be covered as well. enabling the link needs to be covered as well.
The preferred way to address these in a Control Plane enabled network The preferred way to address these in a Control Plane enabled network
is neighbour discovery including exchange of link characteristics and is neighbour discovery including exchange of link characteristics and
link property correlation. The general mechanisms are covered in link property correlation. The general mechanisms are covered in
RFC4209 [LMP-WDM] and RFC 4204[LMP] which provides the necessary [RFC4209] and [RFC4204] which provides the necessary protocol
protocol framework to exchange those characteristics between client framework to exchange those characteristics between client and Black
and black link. LMP-WDM is not intended for exchanging routing or Link. LMP-WDM is not intended for exchanging routing or signaling
signaling information nor to provision the lambda in the transceiver information nor to provision the lambda in the transceiver but
but covers: covers:
1. Control channel management 1. Control channel management
2. Link property correlation 2. Link property correlation
3. Link verification 3. Link verification
4. Fault management 4. Fault management
Extensions to LMP/LMP-WDM covering the parameter sets (application Extensions to LMP covering the parameter sets (e.g. application
codes) are needed. Additionally, when client and server side are codes) are needed. Additionally, when client and server side are
managed by different operational entities, link state exchange is managed by different operational entities, the link state may be
required to align the management systems. useful to help the management system to do troubleshooting or alarm
correlation.
4.2.1. Considerations using GMPLS signaling 4.2.1. Considerations Using GMPLS Signaling
The deployment of single channel optical interfaces is leading to The deployment of single channel optical interfaces is leading to
some functional changes related to the control plane models and has some functional changes related to the control plane models and has
therefore some impact on the existing interfaces especially in the therefore some impact on the existing interfaces especially in the
case of a model where the edge node requests resources from the core case of a model where the edge node requests resources from the core
node and the edges node do not participate in the routing protocol node and the edge node do not participate in the routing protocol
instance that runs among the core nodes. RFC 4208 [RFC4208] defines instance that runs among the core nodes. [RFC4208] defines the GMPLS
the GMPLS UNI that can be used between edge and core node. In case UNI that can be used between edge and core node. In case of
of integrated interfaces deployment additional functionalities are integrated interfaces deployment additional functionalities are
needed to setup a connection. needed to setup a connection.
It is necessary to differentiate between topology/signalling It is necessary to differentiate between topology/signalling
information and configuration parameters that are needed to setup a information and configuration parameters that are needed to setup a
wavelength path. RSVP-TE could be used for the signalling and the wavelength path. Using RSVP-TE could be used for the signalling and
reservation of the wavelength path. But there are additional the reservation of the wavelength path. But there are additional
information needed before RSVP-TE can start the signalling process. information needed before RSVP-TE can start the signalling process.
There are three possibilities to proceed: There are three possibilities to proceed:
a. Using RSVP-TE only for the signalling and LMP as described above a. Using RSVP-TE only for the signalling and LMP as described above
to exchange information to configure the optical interface within to exchange information on the configured optical interface
the edge node or within the edge node
b. RSVP-TE (typically with loose ERO) to transport additional b. RSVP-TE (typically with loose ERO) to transport additional
information information
c. Leaking IGP information instead of exchanging this information c. Leaking IGP information instead of exchanging this information
needed from the optical network to the edge node (UNI will be needed from the optical network to the edge node (UNI will be
transformed to a border-peer model, see RFC 5146) transformed to a border-peer model, see [RFC5146] )
Furthermore following issues should be addressed: Furthermore following issues should be addressed:
a) The Communication between peering edge nodes using an out of band a) The transceivers of peering edge nodes must be compatible. For
control channel. The two nodes should exchange their optical example, it may be required to know about FEC, modulation scheme,
capabilities. An extended version of LMP is needed to exchange FEC etc. Depending on where the information is available, compatibility
Modulation scheme, etc. that must be the same. It would be helpful check may either happen before signaling, when the signaling reaches
to define some common profiles that will be supported. Only if the the optical network (e.g. at path computation time), or in the tail
profiles match with both interface capabilities it is possible start end node. An extended version of LMP is needed to exchange this
signaling. 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 b) Due to the bidirectional wavelength path that must be setup, the
upstream edge node must include a wavelength value into the RSVP-TE 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 Path message. But in the case of a UNI model the client device may
not have full information about which wavelength must/should be not have full information about which wavelength must/should be
selected, whereas this information must be exchanged between the edge selected, whereas this information must be exchanged between the edge
and the core node. The special value defined in and the core node. The special value defined in
[Network-Assigned-Upstream-Label] allows the optical network to [Network-Assigned-Upstream-Label] allows the optical network to
assign the actual wavelength to be used by the upstream transponder, assign the actual wavelength to be used by the upstream transponder,
which is a simple and efficient solution to this issue. which is a simple and efficient solution to this issue.
5. Use cases 5. Use Cases
A Comparison with the traditional operation scenarios provides an A comparison with the traditional operation scenarios provides an
insight of similarities and distinctions in operation and management insight of similarities and distinctions in operation and management
of DWDM interfaces. The following use cases provide an overview of DWDM interfaces. The following use cases provide an overview
about operation and maintenance processes. about operation and maintenance processes.
5.1. Service Setup 5.1. Service Setup
It is necessary to differentiate between different operational issues It is necessary to differentiate between different operational issues
for setting up a light path (a DWDM connection is specific in having for setting up a light path (a DWDM connection is specific in having
defined maximum impairments) within an operational network. defined maximum impairments) within an operational network.
The first step is to determine if transceivers located at different The first step is to determine if transceivers located at different
end-points are interoperable, i.e. support a common set of end-points are interoperable, i.e. support a common set of
operational parameters. In this step it is required to determine operational parameters. In this step it is required to determine
transceiver capabilities in a way to be able to correlate them for transceiver capabilities in a way to be able to correlate them for
interoperability purposes. Such parameters include modulation interoperability purposes. Such parameters include modulation
scheme, modulation parameters, FEC to name a few. If both scheme, modulation parameters, FEC to name a few. If both
transceivers are controlled by the same NMS or CP, such data is transceivers are controlled by the same NMS or CP, such data is
readily available. However in cases like Fig.4 a protocol need to be readily available. However in cases like Figure 4, a protocol needs
used to inform the controlling instance (NMS or CP) about transceiver to be used to inform the controlling instance (NMS or CP) about
parameters. It is suggested to extend LMP for that purpose. transceiver parameters. It is suggested to extend LMP for that
purpose.
The second step is to determine the feasibility of a lightpath The second step is to determine the feasibility of a lightpath
between two transceivers without applying an optical signal. between two transceivers without applying an optical signal.
Understanding the limitations of the transceiver pair, a route Understanding the limitations of the transceiver pair, a path through
through tho optical network has to be found, whereby each route has tho optical network has to be found, whereby each path has an
an individual set of impairments deteriorating a wavelength traveling individual set of impairments deteriorating a wavelength traveling
along that route. Since a single transceiver can support multiple along that path. Since a single transceiver can support multiple
parameter sets, the selection of a route may limit the permissible parameter sets, the selection of a path may limit the permissible
parameter sets determined in step1. parameter sets determined in previous steps.
The third step is then to setup the connection itself and to The third step is then to setup the connection itself and to
determine the Wavelength. This is done using the NMS of the optical determine the Wavelength. This is done using the NMS of the optical
transport network or by means of a control plane interaction such as transport network or by means of a control plane interaction such as
signaling and includes the route information as well as the parameter signaling and includes the path information as well as the parameter
set information necessary to enable communication. set information necessary to enable communication.
In a fourth step, Optical monitoring is activated in the WDM network In a fourth step, optical monitoring is activated in the WDM network
in order to monitor the status of the connection. The monitor in order to monitor the status of the connection. The monitor
functions of the optical interfaces at the terminals are also functions of the optical interfaces at the terminals are also
activated in order to monitor the end to end connection. activated in order to monitor the end to end connection.
Furthermore it should be possible to automate this step. After Furthermore it should be possible to automate this step. After
connecting the client device towards the first control plane managed connecting the client device to the neighbor control plane-enabled
transport node a control connection may e.g. be automatically transport node, a control adjacency may be automatically established,
established using LMP. e.g. using LMP.
5.2. Link monitoring Use Cases 5.2. Link Monitoring Use Cases
The use cases described below are assuming that power monitoring The use cases described below are assuming that power monitoring
functions are available in the ingress and egress network element of functions are available in the ingress and egress network element of
the DWDM network, respectively. By performing link property the DWDM network, respectively. By performing link property
correlation it would be beneficial to include the current transmit correlation it would be beneficial to include the current transmit
power value at reference point Ss and the current received power power value at reference point Ss and the current received power
value at reference point Rs. For example if the Client transmitter value at reference point Rs. For example if the Client transmitter
power has a value of 0dBm and the ROADM interface measured power is 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 -6dBm the fiber patch cord connecting the two nodes may be pinched or
the connectors are dirty. As discussed before, the actual route or the connectors are dirty. As discussed before, the actual path or
selection of a specific wavelength within the allowed set is outside selection of a specific wavelength within the allowed set is outside
the scope of LMP. The computing entities (e.g. the first optical the scope of LMP. The computing entities (e.g. the first optical
node originating the circuit) can rely on GMPLS IGP (OSPF) to node originating the circuit) can rely on GMPLS IGP (OSPF) to
retrieve all the information related to the network, calculate the retrieve all the information related to the network, calculate the
path to reach the endpoint and signal the path implementation through path to reach the endpoint and signal the path implementation through
the network via RSVP-TE. the network via RSVP-TE.
G.698.2 defines a single channel optical interface for DWDM systems G.698.2 defines a single channel optical interface for DWDM systems
that allows interconnecting network-external optical transponders that allows interconnecting network-external optical transponders
across a DWDM network. The optical transponders are external to the across a DWDM network. The optical transponders are external to the
DWDM network. This so-called 'black link' approach illustrated in DWDM network. This so-called 'Black Link' approach illustrated in
Figure 5-1 of G.698.2 and a copy of this figure is provided below. Fig. 5-1 of G.698.2 and a copy of this figure is provided below in
The single channel fiber link between the Ss/Rs reference points and Figure 5. The single channel fiber link between the Ss/Rs reference
the ingress/egress port of the network element on the domain boundary points and the ingress/egress port of the network element on the
of the DWDM network (DWDM border NE) is called access link in this domain boundary of the DWDM network (DWDM border NE) is called access
contribution. Based on the definition in G.698.2 it is part of the link. Based on the definition in G.698.2 it is part of the DWDM
DWDM network. The access link is typically realized as a passive network. The access link is typically realized as a passive fiber
fiber link that has a specific optical attenuation (insertion loss). link that has a specific optical attenuation (insertion loss). As
As the access link is an integral part of the DWDM network, it is the access link is an integral part of the DWDM network, it is
desirable to monitor its attenuation. Therefore, it is useful to desirable to monitor its attenuation. Therefore, it is useful to
detect an increase of the access link attenuation, for example, when detect an increase of the access link attenuation, for example, when
the access link fiber has been disconnected and reconnected the access link fiber has been disconnected and reconnected
(maintenance) and a bad patch panel connection (connector) resulted (maintenance) and a bad patch panel connection (connector) resulted
in a significantly higher access link attenuation (loss of signal in in a significantly higher access link attenuation (loss of signal in
the extreme case of an open connector or a fiber cut). In the the extreme case of an open connector or a fiber cut). In the
following section, two use cases are presented and discussed: following section, two use cases are presented and discussed:
1) pure access link monitoring 1) pure access link monitoring
2) access link monitoring with a power control loop 2) access link monitoring with a power control loop
These use cases require a power monitor as described in G.697 (see 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 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 incoming or outgoing single channel signal. The use case where a
power control loop is in place could even be used to compensate an power control loop is in place could even be used to compensate an
increased attenuation if the optical transmitter can still be increased attenuation if the optical transmitter can still be
operated within its output power range defined by its application operated within its output power range defined by its application
code. code.
Figure 5 Access Link Power Monitoring Use case 1: Access Link monitoring
+--------------------------+ +--------------------------+
| P(in) = P(Tx) - a(Tx) | | P(in) = P(Tx) - a(Tx) |
| ___ | | ___ |
+----------+ | \ / Power Monitor | +----------+ | \ / Power Monitor |
| | P(Tx) | V P(in) | | | P(Tx) | V P(in) |
| +----+ | Ss //\\ | | |\ | | +----+ | Ss //\\ | | |\ |
| | TX |----|-----\\//------------------->| \ | | | TX |----|-----\\//------------------->| \ |
| +----+ | Access Link (AL-T) | . | | | | +----+ | Access Link (AL-T) | . | | |
| | attenuation a(Tx) | . | |==============> | | attenuation a(Tx) | . | |==============>
skipping to change at page 17, line 44 skipping to change at page 18, line 44
- For AL-T monitoring: P(Tx) and a(Tx) must be known - For AL-T monitoring: P(Tx) and a(Tx) must be known
- For AL-R monitoring: P(RX) and a(Rx) 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 An alarm shall be raised if P(in) or P(Rx) drops below a
configured threshold (t [dB]): configured threshold (t [dB]):
- P(in) < P(Tx) - a(Tx) - t (Tx direction) - P(in) < P(Tx) - a(Tx) - t (Tx direction)
- P(Rx) < P(out) - a(Rx) - t (Rx direction) - P(Rx) < P(out) - a(Rx) - t (Rx direction)
- a(Tx) =| a(Rx) - a(Tx) =| a(Rx)
Alarms and events can be shared between Client and Network Alarms and events can be shared between Client and Network
via LMP according to RFC 4204 and RFC 4209[LMP] via LMP.
Figure 5: Extended LMP Model Figure 5: Access Link Power Monitoring
5.2.1. Pure Access Link (AL) Monitoring Use Case 5.2.1. Pure Access Link (AL) Monitoring Use Case
Figure 6 illustrates the access link monitoring use case and the Figure 6 illustrates the access link monitoring use case and the
different physical properties involved that are defined below: different physical properties involved that are defined below:
- Ss, Rs: Single Channel reference points - Ss, Rs: Single Channel reference points
- P(Tx): current optical output power of transmitter Tx - P(Tx): current optical output power of transmitter Tx
- a(Tx): access link attenuation in Tx direction (external - a(Tx): access link attenuation in Tx direction (external
transponder point of view) transponder point of view)
skipping to change at page 18, line 46 skipping to change at page 19, line 46
Access Link monitoring process: Access Link monitoring process:
- Tx direction: the measured optical input power Pin is compared - Tx direction: the measured optical input power Pin is compared
with the expected optical input power P(Tx) - a(Tx). If the with the expected optical input power P(Tx) - a(Tx). If the
measured optical input power P(in) drops below the value measured optical input power P(in) drops below the value
(P(Tx) - a(Tx) - t) a low power alarm shall be raised indicating (P(Tx) - a(Tx) - t) a low power alarm shall be raised indicating
that the access link attenuation has exceeded a(Tx) + t. that the access link attenuation has exceeded a(Tx) + t.
- Rx direction: the measured optical input power P(Rx) is - Rx direction: the measured optical input power P(Rx) is
compared with the expected optical input power P(out) - a(Rx). compared with the expected optical input power P(out) - a(Rx).
If the measured optical input power P(Rx) drops below the value If the measured optical input power P(Rx) drops below the value
(P(out) - a(Rx) - t) a (P(out) - a(Rx) - t) a low power alarm shall be raised indicating
low power alarm shall be raised indicating that the access link that the access link attenuation has exceeded a(Rx) + t.
attenuation has exceeded a(Rx) + t.
- to avoid toggling errors, the low power alarm threshold shall be - to avoid toggling errors, the low power alarm threshold shall be
lower than the alarm clear threshold. lower than the alarm clear threshold.
Figure 6 Use case 1: Access Link monitoring Use case 1: Access Link monitoring
+----------+ +--------------------------+ +----------+ +--------------------------+
| +------+ | P(Tx), P(Rx) | +-------+ | | +------+ | P(Tx), P(Rx) | +-------+ |
| | | | =================> | | | | | | | | =================> | | | |
| | LMP | | P(in), P(out) | | LMP | | | | LMP | | P(in), P(out) | | LMP | |
| | | | <================= | | | | | | Agent| | <================= | | Agent | |
| +------+ | | +-------+ | | +------+ | | +-------+ |
| | | | | | | |
| | | P(in) - P(Tx) - a(Tx) | | | | P(in) - P(Tx) - a(Tx) |
| | | ___ | | | | ___ |
| | | \ / Power Monitor | | | | \ / Power Monitor |
| | P(Tx) | V | | | P(Tx) | V |
| +----+ | Ss //\\ | | |\ | | +----+ | Ss //\\ | | |\ |
| | TX |----|-----\\//------------------->| \ | | | TX |----|-----\\//------------------->| \ |
| +----+ | Access Link (AL-T) | . | | | | +----+ | Access Link (AL-T) | . | | |
| | attenuation a(Tx) | . | |==============> | | attenuation a(Tx) | . | |==============>
skipping to change at page 19, line 49 skipping to change at page 20, line 49
- For AL-T monitoring: P(Tx) and a(Tx) must be known - For AL-T monitoring: P(Tx) and a(Tx) must be known
- For AL-R monitoring: P(RX) and a(Rx) 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 An alarm shall be raised if P(in) or P(Rx) drops below a
configured threshold (t [dB]): configured threshold (t [dB]):
- P(in) < P(Tx) - a(Tx) - t (Tx direction) - P(in) < P(Tx) - a(Tx) - t (Tx direction)
- P(Rx) < P(out) - a(Rx) - t (Rx direction) - P(Rx) < P(out) - a(Rx) - t (Rx direction)
- a(Tx) = a(Rx) - a(Tx) = a(Rx)
Alarms and events can be shared between Client and Network Alarms and events can be shared between Client and Network
via LMP according to RFC 4204 and RFC 4209[LMP] via LMP according to [RFC4204] and [RFC4209]
Figure 6: Extended LMP Model Figure 6: Extended LMP Model
5.2.2. Power Control Loop Use Case 5.2.2. Power Control Loop Use Case
This use case is based on the access link monitoring use case as This use case is based on the access link monitoring as
described above. In addition, the border NE is running a power described above. In addition, the border NE is running a power
control application that is capable to control the optical output control application that is capable to control the optical output
power of the single channel tributary signal at the output port power of the single channel tributary signal at the output port
of the border DWDM NE (towards the external receiver Rx) and the of the border DWDM NE (towards the external receiver Rx) and the
optical output power of the single channel tributary signal at optical output power of the single channel tributary signal at
the external transmitter Tx within their known operating range. the external transmitter Tx within their known operating range.
The time scale of this control loop is typically relatively slow The time scale of this control loop is typically relatively slow
(e.g. some 10s or minutes) because the access link attenuation (e.g. some 10s or minutes) because the access link attenuation
is not expected to vary much over time (the attenuation only is not expected to vary much over time (the attenuation only
changes when re-cabling occurs). changes when re-cabling occurs).
From a data plane perspective, this use case does not require From a data plane perspective, this use case does not require
additional data plane extensions. It does only require a protocol additional data plane extensions. It does only require a protocol
extension in the control plane (e.g. this LMP draft) that allows extension in the control plane (e.g. this LMP draft) that allows
the power control application residing in the DWDM border NE to the power control application residing in the DWDM border NE to
modify the optical output power of the DWDM domain-external modify the optical output power of the DWDM domain-external
transmitter Tx within the range of the currently used application transmitter Tx within the range of the currently used application
code. Figure 5 below illustrates this use case utilizing the LMP code. Figure 7 below illustrates this use case utilizing
protocol with extensions defined in this draft. LMP with the extensions identified in this document.
Figure 7 Use case 2: Power Control Loop Use case 2: Power Control Loop
+----------+ +--------------------------+ +----------+ +--------------------------+
| +------+ | P(Tx),P(Rx),Set(Pout) | +-------+ +--------+ | | +------+ | P(Tx),P(Rx),Set(Pout) | +-------+ +--------+ |
| | | | ====================> | | | | Power | | | | | | ====================> | | | | Power | |
| | LMP | | P(in),P(out),Set(PTx) | | LMP | |Control | | | | LMP | | P(in),P(out),Set(PTx) | | LMP | |Control | |
| | | | <==================== | | | | Loop | | | | | | <==================== | | | | Loop | |
| +------+ | | +-------+ +--------+ | | +------+ | | +-------+ +--------+ |
| | | | | | | | | |
| +------+ | | P(in) = P(Tx) - a(Tx) | | +------+ | | P(in) = P(Tx) - a(Tx) |
| |C.Loop| | | ___ | | |C.Loop| | | ___ |
skipping to change at page 21, line 42 skipping to change at page 22, line 42
| | attenuation a(Rx) | . | |<======= | | attenuation a(Rx) | . | |<=======
+----------+ | VOA(out) | | | +----------+ | VOA(out) | | |
| <--<|-------| / | | <--<|-------| / |
P(Rx) = P(out) - a(Rx) | |/ | P(Rx) = P(out) - a(Rx) | |/ |
| | | |
| ROADM | | ROADM |
+--------------------------+ +--------------------------+
Figure 7: Power control loop Figure 7: Power control loop
- The Power Control Loops in Transponder and ROADM controls - The power control loop in transponders and ROADMs controls
the Variable Optical Attenuators (VOA) to adjust the proper the Variable Optical Attenuators (VOA) to adjust the proper
power in base of the ROADM and Receiver caracteristics and power in base of the ROADM and Receiver caracteristics and
the Access Link attenuation the Access Link attenuation
6. Requirements 6. Requirements
Even if network architectures becomes more complex the management and Even if network architectures becomes more complex, management and
operation as well as the provisioning process should have a higher operation as well as the provisioning process should have a higher
degree of automation or should be fully automated. Simplifying and degree of automation or should be fully automated. Simplifying and
automating the entire management and provisioning process of the automating the entire management and provisioning process of the
network in combination with a higher link utilization and faster network in combination with a higher link utilization and faster
restoration times will be the major requirements that has been restoration times will be the major requirements that have been
addressed in this section. addressed in this section.
Data Plane interoperability as defined for example in [ITU.G698.2] is Data plane interoperability as defined for example in [ITU.G698.2] is
a precondition to ensure plain solutions and allow the usage of a precondition to take full benefit from standardized interfaces
standardized interfaces between network and control/management plane. between network and control/management plane.
The following requirements are focusing on the usage of DWDM The following requirements are focusing on the usage of DWDM
interfaces. interfaces.
1 To ensure a lean management and provisioning process of single 1 A standardized procedure to setup an optical connection MUST
channel interfaces management and control plane of the client be defined and implemented in DWDM and client devices
and DWDM network MUST be aware of the parameters of the (containing the single channel optical interface).
interfaces and the optical network to properly setup the optical
connection.
2 A standard-based northbound API (to network management system) 2 In order to ensure a lean management and provisioning of single
channel interfaces, the management and control plane of both the
client and DWDM network MUST be aware of the right set of
parameters. Such parameters define the interfaces and the optical
network and are needed to properly setup the optical connection.
3 A standard-based northbound API (to network management system)
based on Netconf SHOULD be supported, alternatively SNMP MAY based on Netconf SHOULD be supported, alternatively SNMP MAY
be supported too. be supported too.
3 A standard-based data model for single channel interfaces MUST be 4 A standard-based data model for single channel interfaces MUST be
supported to exchange optical parameters with control/management supported to exchange optical parameters with control/management
plane. plane.
4 Netconf SHOULD be used also for configuration of the single 5 Netconf SHOULD be used also for configuration of the single
channel interfaces including the power setting channel interfaces including the power setting
5 LMP SHOULD be extended and used in cases where optical 6 LMP SHOULD be extended and used in cases where optical
parameters need to be exchanged between peer nodes to correlate parameters need to be exchanged between two nodes to correlate
link characteristics and adopt the working mode of the single link characteristics and adopt the working mode of the single
channel interface. channel interface.
6 LMP MAY be used to adjust the output power of the single 7 LMP MAY be used to adjust the output power of the single
channel DWDM interface to ensure that the interface works in channel DWDM interface to ensure that the interface works in
the right range. the right range.
7 RSVP-TE MAY be used to exchange some relevant parameters between 8 RSVP-TE SHOULD be used to exchange some relevant parameters
the client and the optical node (e.g. the label value), without between the client and the optical node (e.g. the label value),
preventing the network to remain in charge of the optical path without preventing the network to remain in charge of the optical
computation path computation
8 Power monitoring functions at both ends of the DWDM connection 9 Power monitoring functions at both ends of the DWDM connection
SHOULD be used to further automate the setup and shoutdown MAY be used to further automate the setup and shoutdown
process of the optical interfaces. process of the optical interfaces.
9 A standardized procedure to setup an optical connection SHOULD 10 In fault cases, the network SHOULD be able to recover wavelengths,
be defined and implemented in DWDM and client devices either using pre-defined paths or dynamic re-routing.
(containing the single channel optical interface).
10 Pre-tested and configured backup paths SHOULD be stored in so
called backup profiles. In fault cases this wavelength routes
SHOULD be used to recover the service.
11 LMP MAY be used to monitor and observe the access link. 11 LMP MAY be used to monitor and observe the access link.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank all who supported the work with The authors would like to thank all who supported the work with
fruitful discussions and contributions. fruitful discussions and contributions.
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
skipping to change at page 28, line 5 skipping to change at page 29, line 5
[Network-Assigned-Upstream-Label] [Network-Assigned-Upstream-Label]
Internet Engineering Task Force, "Generalized Multi- Internet Engineering Task Force, "Generalized Multi-
Protocol Label Switching (GMPLS) Resource reSerVation Protocol Label Switching (GMPLS) Resource reSerVation
Protocol with Traffic Engineering (RSVP- TE) mechanism Protocol with Traffic Engineering (RSVP- TE) mechanism
that enables the network to assign an upstream label for a that enables the network to assign an upstream label for a
bidirectional LSP", draft-ietf-teas-network-assigned- bidirectional LSP", draft-ietf-teas-network-assigned-
upstream-label draft-ietf-teas-network-assigned-upstream- upstream-label draft-ietf-teas-network-assigned-upstream-
label, June 2017. 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>.
Authors' Addresses Authors' Addresses
Ruediger Kunze (editor) Ruediger Kunze (editor)
Deutsche Telekom Deutsche Telekom
Winterfeldtstr. 21-27 Winterfeldtstr. 21-27
10781 Berlin 10781 Berlin
Germany Germany
Phone: +491702275321 Phone: +491702275321
Email: RKunze@telekom.de Email: RKunze@telekom.de
skipping to change at page 28, line 36 skipping to change at page 29, line 41
Nokia Nokia
Lorenzstrasse, 10 Lorenzstrasse, 10
70435 Stuttgart 70435 Stuttgart
Germany Germany
Phone: +4971182143125 Phone: +4971182143125
Email: Dieter.Beller@nokia.com Email: Dieter.Beller@nokia.com
Gabriele Galimberti (editor) Gabriele Galimberti (editor)
Cisco Cisco
Via S. Maria Molgora, 48 Via S. Maria Molgora, 48c
20871 - Vimercate 20871 - Vimercate
Italy Italy
Phone: +390392091462 Phone: +390392091462
Email: ggalimbe@cisco.com Email: ggalimbe@cisco.com
Julien Meuric Julien Meuric
France Telecom Orange Orange
2, Avenue Pierre Marzin 2, Avenue Pierre Marzin
22307 Lannion Cedex 22307 Lannion Cedex
France France
Phone: +33 2 96 05 28 28 Phone: +33
Email: julien.meuric@orange.com Email: julien.meuric@orange.com
 End of changes. 87 change blocks. 
230 lines changed or deleted 238 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/