draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-09.txt   draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-10.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: June 18, 2018 Juniper Expires: December 8, 2018 Juniper
D. Beller D. Beller
Nokia Nokia
G. Galimberti, Ed. G. Galimberti, Ed.
Cisco Cisco
J. Meuric J. Meuric
Orange Orange
December 15, 2017 June 6, 2018
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-09 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-10
Abstract Abstract
The control and management of DWDM interfaces are a precondition for The control and management of DWDM interfaces are a precondition for
enhanced multilayer networking. They are needed to ensure an enhanced multilayer networking. They are needed to ensure an
efficient data transport, to meet the requirements requested by efficient data transport, to meet the requirements requested by
today's IP-services and to provide a further automation of network today's IP-services and to provide a further automation of network
provisioning and operations. This document describes use cases, provisioning and operations. This document describes use cases,
requirements and solutions for the control and management of optical requirements and solutions for the control and management of optical
interface parameters according to different types of single channel interface parameters according to different types of single channel
DWDM interfaces. The focus is on automating the network provisioning DWDM interfaces. The focus is on automating the network provisioning
process irrespective on how it is triggered i.e. by EMS, NMS or process irrespective on how it is triggered i.e. by Element Manager
GMPLS. This document covers management and control considerations in System (EMS), Network Management System (NMS) or Generalized Multi
different scenarios of single channel DWDM interfaces. The purpose Protocol Label Switching (GMPLS). This document covers management
is to identify the necessary information and processes to be used by and control considerations in different scenarios of single channel
control or management systems to properly and efficiently drive the DWDM interfaces. The purpose is to identify the necessary
network. information and processes to be used by 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 https://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 June 18, 2018.
This Internet-Draft will expire on December 8, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://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 . . . . . . . . . . . . . . . . . . 4
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 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 . . 6
3.1.1. Multivendor DWDM Line System with Transponders . . . 5 3.1.1. Multivendor DWDM Line System with Transponders . . . 6
3.1.2. Integrated Single Channel DWDM Deployments on the 3.1.2. Integrated Single Channel DWDM Deployments on the
Client Site . . . . . . . . . . . . . . . . . . . . . 7 Client Site . . . . . . . . . . . . . . . . . . . . . 7
4. Solutions for Managing and Controlling Single Channel Optical 4. Solutions for Managing and Controlling Single Channel Optical
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Separate Operation and Management Approaches . . . . . . 10 4.1. Separate Operation and Management Approaches . . . . . . 10
4.1.1. Direct Connection to the Management System . . . . . 10 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) . . . . . . . . . . . . . . . . 11 (First Optical Node) . . . . . . . . . . . . . . . . 11
4.2. Control Plane Considerations . . . . . . . . . . . . . . 13 4.2. Control Plane Considerations . . . . . . . . . . . . . . 13
4.2.1. Considerations Using GMPLS Signaling . . . . . . . . 14 4.2.1. Considerations Using GMPLS Signaling . . . . . . . . 14
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Link Monitoring Use Cases . . . . . . . . . . . . . . . . 16 5.2. Link Monitoring Use Cases . . . . . . . . . . . . . . . . 16
5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 19 5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 19
5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 21 5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 21
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The usage of external single channel DWDM interfaces (e.g. in The usage of external single channel Dense Wavelenght Division
routers) connected to a DWDM Network (e.g. router connected to a Multiplexing (DWDM) interfaces (e.g. in routers) connected to a DWDM
network of ROADMs and optical amplifiers) adds a further networking Network (e.g. router connected to a network of Reconfigurable Optical
option for operators but requires an harmonised control and Add Drop Multiplexers (ROADM) and optical amplifiers) adds a further
management plane interaction between the different network domains. 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 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 combining the Packet and Transport high level of redundancy combining the Packet and Transport
restoration. Both network domains were operated and managed restoration. Both network domains were operated and managed
separately. This is the status quo in many carrier networks today. separately. This is the status quo in many carrier networks today.
In the case of deployments where the optical transport interface In the case of deployments where the optical transport interface
moves into the client device (e.g. router) an interaction between moves into the client device (e.g. router) an interaction between
those domains becomes necessary (e.g. Lambda reprovisioning due to those domains becomes necessary (e.g. Lambda reprovisioning due to
an optical restoration). 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. The interfaces in carrier networks in an efficient manner. The
interfaces between the two layers can be wither gray or coloured. interfaces between the two layers can be either gray or coloured.
Although Optical routing and wavelength assignment based on WSON is Although Optical routing and wavelength assignment based on
out of scope, they can benefit from the optical parameters that are Wavelenght Switched Optical Network (WSON) is out of scope, they can
exchanged between the Client and the DWDM Network. Also, the benefit from the optical parameters that are exchanged between the
wavelength ordering process and determining the demand for a new Client and the DWDM Network. Also, the wavelength ordering process
wavelength path through the network are out of scope. 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 Note that the Control and Management Planes are two separate entities
that may handle 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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "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] describes interpretations of these key words While RFC 2119 [RFC2119] RFC 8174 [RFC8174] describe interpretations
in terms of protocol specifications and implementations, they are of these key words in terms of protocol specifications and
used in this document to describe design requirements for protocol implementations, they are used in this document to describe design
extensions. 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 Wavelenght Division Multiplexing (WDM)
where the optical line system and the transponders are tightly netwoks are single vendor networks where the optical line system and
integrated. The DWDM interface migration from integrated the transponders are tightly integrated. The DWDM interface
transponders to third party transponders or colored interfaces change migration from integrated transponders to third party transponders or
this scenario and introduces a standardized interface at the level of colored interfaces change this scenario and introduces a standardized
OCh between the DWDM interface and the DWDM network. 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 Black Link: The Black Link [ITU-T.G.698.2] allows supporting an
optical transmitter/receiver pair (of a single vendor or from optical transmitter/receiver pair (of a single vendor or from
different vendors) to provide a single optical channel interface and different vendors) to provide a single optical channel interface and
transport it over an optical network composed of amplifiers, filters, transport it over an optical network composed of amplifiers, filters,
add-drop multiplexers these being possibly from different vendors. add-drop multiplexers these being possibly from different vendors.
Therefore the standard defines the ingress and egress parameters for Therefore the standard defines the ingress and egress parameters for
the optical interfaces at the reference points Ss and Rs. the optical interfaces at the reference points Source side (Ss) and
Receive side (Rs).
Single Channel DWDM Interface: The single channel interfaces to DWDM Single Channel DWDM Interface: The single channel interfaces to DWDM
systems defined in [ITU-T.G.698.2], which currently include the systems defined in [ITU-T.G.698.2], which currently include the
following features: channel frequency spacing: 50 GHz and wider following features: channel frequency spacing: 50 GHz and wider
(defined in [ITU-T.G.694.1]; bit rate of single channel: Up to 10 (defined in [ITU-T.G.694.1] ); bit rate of single channel: Up to 10
Gbit/s. Future revisions are expected to include application codes Gbit/s. Future revisions are expected to include application codes
for bit rates up to 40 Gb/s. for bit 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 [ITU-T.G.805]: the extent of resources which Administrative domain [ITU-T.G.805]: the extent of resources which
skipping to change at page 5, line 15 skipping to change at page 5, line 31
Control Plane [ITU-T.G.8081]: Through signaling, the control plane Control Plane [ITU-T.G.8081]: Through signaling, the control plane
sets up and releases connections, may restore a connection in case of sets up and releases connections, may restore a connection in case of
a failure, and also performs other functions (e.g., neighbor a failure, and also performs other functions (e.g., neighbor
discovery, topology distribution) in support of those. discovery, topology distribution) in support of those.
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-T.G.872]. regeneration) as defined in [ITU-T.G.872].
Line System: A Line System is a portion of the network including Add Line System: A Line System is a portion of the network including
Drop Multiplexers (ROADM) Line Amplifiers and the the fibers Reconfigurable Add Drop Multiplexers (ROADM) Line Amplifiers and the
connecting them. 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-T.G.872]. the DWDM side of a transponder as defined in [ITU-T.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
skipping to change at page 6, line 39 skipping to change at page 7, line 10
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 a set of 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 (Intra Domain Interface) as
as transversely compatible and multi-vendor interface within one shown in Figure 1 as DWDM transversely compatible and multi-vendor
administrative domain controlled by the network operator. interface within one administrative domain controlled by the network
operator.
SNMP/SMI, Yang models and LMP TLV to support the direct exchange of SNMP/Simple Management Interface (SMI), Netconf/Restcong and Link
Management Protocol (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.
IETF working groups are encouraged to use the NETCONF/YANG standards
for configuration, especially in new charters. SNMP MIB modules
creating and modifying configuration state should only be produced by
working groups in cases of clear utility and consensus to use SNMP
write operations for configuration, and in consultation with the OPS
ADs/MIB doctors. 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 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. Among interfaces, multi-vendor interconnection can also be achieved. Among
the possible use cases, it may be used to remove the need for one the possible use cases, it may be used to remove the need for one
short reach transmitter and receiver pair per channel (eliminating short reach transmitter and receiver pair per channel (eliminating
the transponders). 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 ROADMs.
|==================== Black Link =======================| |==================== Black Link =======================|
+-------------------------------------------------+ +-------------------------------------------------+
Ss | | DWDM Network Elements | | Rs Ss | | DWDM Network Elements | | Rs
+---+ | | | \ / | | | +---+ +---+ | | | \ / | | | +---+
Tx L1---|->| \ +------+ +------+ / |--|-->Rx L1 Tx L1---|->| \ +------+ +------+ / |--|-->Rx L1
+---+ | | | | | +------+ | | | | | +---+ +---+ | | | | | +------+ | | | | | +---+
+---+ | | | | | | | | | | | | +---+ +---+ | | | | | | | | | | | | +---+
Tx L2---|->| OM |-|>|------|->| ROADM|--|------|->| OD |--|-->Rx L2 Tx L2---|->| OM |-|>|------|->| ROADM|--|------|->| OD |--|-->Rx L2
skipping to change at page 9, line 5 skipping to change at page 9, line 5
Linear DWDM network as per ITU-T G.698.2 Linear DWDM network as per ITU-T G.698.2
Figure 2: Linear Black Link Figure 2: Linear Black Link
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, Netconf/Restconf and LMP TLV to support the direct exchange
information between the client and the network management and control of information between the client and the network management and
plane will be specified in further documents. control 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 a hierarchical 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
skipping to change at page 10, line 28 skipping to change at page 10, line 28
| NMS | | NMS |
|_____| |_____|
/_____/ /_____/
| |
| |
| |
+---+---+ +---+---+
+----->+ EMS | +----->+ EMS |
/ | | / | |
/ +-------+ / +-------+
/ | MI SNMP or Yang / | MI SNMP or Netconf/Restconf
SNMP / or Yang | DCN Network SNMP / or Netconf | DCN Network
--------------------+------------------------------- --------------------+-------------------------------
/ +------+-----------------------+ / +------+-----------------------+
/ | +| WDM Domain + | / | +| WDM Domain + |
/ | |\ /| | / | |\ /| |
+---+--+ | | \ |\ / | | +------+ +---+--+ | | \ |\ / | | +------+
| CL |-/C------+-----|OM|----|/-------|OD|----+-------/C-| CL | | CL |-/C------+-----|OM|----|/-------|OD|----+-------/C-| CL |
| |-/C------+-----| |----- /|-----| |----+-------/C-| | | |-/C------+-----| |----- /|-----| |----+-------/C-| |
+------+ | | / \| \ | | +------+ +------+ | | / \| \ | | +------+
| |/ \| | | |/ \| |
| + + | | + + |
skipping to change at page 11, line 18 skipping to change at page 11, line 18
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. [RFC3591] defines managed objects network management application. [RFC3591] defines managed objects
for the optical interface type but needs further extension to cover for the optical interface type but needs further extension to cover
the optical parameters required by this framework document. 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 is not affected
by security issue.
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 should be used in cases where a 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 more integrated relationship between transport node (e.g. OM or OD
or ROADM) and client device is aspired. In that case a combination or ROADM) and client device is aspired. In that case a combination
skipping to change at page 12, line 20 skipping to change at page 12, line 20
+-----+ +-----+
| NMS | | NMS |
|_____| |_____|
/_____/ /_____/
| |
| |
+---+---+ +---+---+
| EMS | | EMS |
| | | |
+-------+ +-------+
| MI SNMP or Yang | MI SNMP or Netconf/Restconf
| |
LMP +------+-----------------------+ LMP +------+-----------------------+
+------------+---+ +| + | +------------+---+ +| + |
| | | |\ /| | | | | |\ /| |
+---+--+ | +-+ \ |\ / | | +------+ +---+--+ | +-+ \ |\ / | | +------+
| CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL | | CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL |
| |-/C------+--- -| |----- /|-----| |----+-------/C-| | | |-/C------+--- -| |----- /|-----| |----+-------/C-| |
+------+ | | / \| \ | | +------+ +------+ | | / \| \ | | +------+
| |/ \| | | |/ \| |
| + + | | + + |
skipping to change at page 12, line 51 skipping to change at page 12, line 51
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 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 between a peer node and an adjacent optical network node as depicted
in Figure 4. in Figure 4.
At the time of writing this document, LMP does not yet support the At the time of writing this document, LMP does not yet support the
transmission of configuration data (information). This functionality transmission of configuration data (information). This functionality
must be added to the protocol. The use of LMP assumes that some form would need to be added to the protocol. The use of LMP assumes that
of a control channel exists between the client node and the WDM some form of a control channel exists between the client node and the
equipment. This may be a dedicated lambda or an Ethernet Link. WDM equipment. This may be a dedicated lambda or an 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. RFC 7689 [RFC7689] plane protocols have been extended for WSON, e.g. RFC 7689 [RFC7689]
) for fixed grid signal and for flexi-grid RFC 7792 [RFC7792] ). One ) 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 important aspect of the Black Link [ITU-T.G.698.2] is the fact that
it includes the wavelength that is supported by the given link. it includes the wavelength that is supported by the given link.
Therefore, the link can logically be considered as a fiber that is Therefore, the link can logically be considered as a fiber that is
skipping to change at page 13, line 28 skipping to change at page 13, line 28
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.
2. Interface first, OLS tuning: The transmitter is switched on first 2. Interface first, Optical Line System (OLS) tuning: The
and can immediately go to the max power allowed since the OLS transmitter is switched on first and can immediately go to the
performs the power tuning. This leads to an intermediate state max power allowed since the OLS performs the power tuning. This
where the receiver does not receive a valid signal while the leads to an intermediate state where the receiver does not
transmitter is sending out one. Alarm suppression mechanisms receive a valid signal while the transmitter is sending out one.
shall be employed to overcome that condition. Alarm suppression mechanisms shall be employed to overcome that
condition.
3. OLS first, interface tuning: At first the OLS is tuned to be 3. OLS first, interface tuning: At first the OLS is tuned to be
transparent for a given wavelength, then transponders need to be transparent for a given wavelength, then transponders need to be
tuned up. Since the OLS in general requires the presence of a tuned up. Since the OLS in general requires the presence of a
wavelength to fine-tune its internal facilities there may be a wavelength to fine-tune its internal facilities there may be a
period where a valid signal is transmitted but the receiver is period where a valid signal is transmitted but the receiver is
unable to detect it. This equally need to be covered by alarm unable to detect it. This equally need to be covered by alarm
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
skipping to change at page 15, line 8 skipping to change at page 15, line 12
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 [RFC5146] ) transformed to a border-peer model, see RFC 5146 [RFC5146] )
Furthermore following issues should be addressed: Furthermore following issues should be addressed:
a) The transceivers of peering edge nodes must be compatible. For a) The transceivers of peering edge nodes must be compatible. For
example, it may be required to know about FEC, modulation scheme, example, it may be required to know about FEC, modulation scheme, The
etc. Depending on where the information is available, compatibility modulation format, the baudrate and many other parameters described
check may either happen before signaling, when the signaling reaches in the drafts reported in the Annex. Depending on where the
the optical network (e.g. at path computation time), or in the tail information is available, compatibility check may either happen
end node. An extended version of LMP is needed to exchange this before signaling, when the signaling reaches the optical network
information in case a. above, and to RSVP-TE as well in b. It would (e.g. at path computation time), or in the tail end node. An
be helpful to define some common profiles that will be supported extended version of LMP is needed to exchange this information in
(e.g. the "application identifier") to summarize interface case a. above, and to RSVP-TE as well in b. It would be helpful to
capabilities: if both profiles match, signaling can succeed and define some common profiles that will be supported (e.g. the
provisioning be achieved. "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.
skipping to change at page 16, line 8 skipping to change at page 16, line 14
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 Figure 4, a protocol needs readily available. However in cases like Figure 4, a protocol needs
to be used to inform the controlling instance (NMS or CP) about to be used to inform the controlling instance (NMS or CP) about
transceiver parameters. It is suggested to extend LMP for that transceiver parameters. It is suggested to extend LMP for that
purpose. 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 path through Understanding the limitations of the transceiver pair, a path through
tho optical network has to be found, whereby each path has an the optical network has to be found, whereby each path has an
individual set of impairments deteriorating a wavelength traveling individual set of impairments deteriorating a wavelength traveling
along that path. Since a single transceiver can support multiple along that path. Since a single transceiver can support multiple
parameter sets, the selection of a path may limit the permissible parameter sets, the selection of a path may limit the permissible
parameter sets determined in previous steps. 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 path 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.
skipping to change at page 19, line 34 skipping to change at page 19, line 34
- The access link attenuation in both directions (a(Tx), a(Rx)) - The access link attenuation in both directions (a(Tx), a(Rx))
is known or can be determined as part of the commissioning is known or can be determined as part of the commissioning
process. Typically, both values are very similar. process. Typically, both values are very similar.
- A threshold value t has been configured by the operator. This - A threshold value t has been configured by the operator. This
should also be done during commissioning. should also be done during commissioning.
- A control plane protocol is in place that allows - A control plane protocol is in place that allows
to periodically send the optical power values P(Tx) and P(Rx) to periodically send the optical power values P(Tx) and P(Rx)
to the control plane protocol instance on the DWDM border NE. to the control plane protocol instance on the DWDM border NE.
This is illustrated in Figure 3. This is illustrated in Figure 3.
- The DWDM border NE is capable to periodically measure the optical - The DWDM border NE is capable to periodically measure the optical
power Pin and Pout as defined in G.697 by power monitoring points power P(in) and P(out) as defined in G.697 by power monitoring
depicted as yellow triangles in the figures below. points depicted as triangles in the figures below.
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 P(in) 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 low power alarm shall be raised indicating (P(out) - a(Rx) - t) a low power alarm shall be raised indicating
that the access link attenuation has exceeded a(Rx) + t. that the access link 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.
Use case 1: Access Link monitoring Use case 2: Access Link monitoring through LMP
+----------+ +--------------------------+ +----------+ +--------------------------+
| +------+ | P(Tx), P(Rx) | +-------+ | | +------+ | P(Tx), P(Rx) | +-------+ |
| | | | =================> | | | | | | | | =================> | | | |
| | LMP | | P(in), P(out) | | LMP | | | | LMP | | P(in), P(out) | | LMP | |
| | Agent| | <================= | | Agent | | | | Agent| | <================= | | Agent | |
| +------+ | | +-------+ | | +------+ | | +-------+ |
| | | | | | | |
| | | P(in) - P(Tx) - a(Tx) | | | | P(in) - P(Tx) - a(Tx) |
| | | ___ | | | | ___ |
skipping to change at page 22, line 5 skipping to change at page 22, line 5
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 7 below illustrates this use case utilizing code. Figure 7 below illustrates this use case utilizing
LMP with the extensions identified in this document. LMP with the extensions identified in this document.
Use case 2: Power Control Loop Use case 3: Power Control Loop
+----------+ +--------------------------+ +----------+ +--------------------------+
| +------+ | P(Tx),P(Rx),Set(Pout) | +-------+ +--------+ | | +------+ |P(Tx),P(Rx),Set(P(out))| +-------+ +--------+ |
| | | | ====================> | | | | 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| | | ___ |
| +------+ | | \ / Power Monitor | | +------+ | | \ / Power Monitor |
| | | P(Tx) | V | | | | P(Tx) | V |
| +------+ | Ss //\\ | | |\ | | +------+ | Ss //\\ | | |\ |
skipping to change at page 23, line 15 skipping to change at page 23, line 15
6. Requirements 6. Requirements
Even if network architectures becomes more complex, 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 have been restoration times will be the major requirements that have been
addressed in this section. addressed in this section.
YANG based network management protocols such as NETCONF [RFC6241] or
RESTCONF [RFC8040] are strongly suggested as the base for the
communication among EMS, Controller and the Data Plane.
Data plane interoperability as defined for example in [ITU-T.G.698.2] Data plane interoperability as defined for example in [ITU-T.G.698.2]
is a precondition to take full benefit from standardized interfaces is a precondition to take full benefit from 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 A standardized procedure to setup an optical connection MUST 1 A procedure to setup an optical connection MUST be defined and
be defined and implemented in DWDM and client devices implemented in DWDM and client devices (containing the single
(containing the single channel optical interface). channel optical interface). The Procedure MAY me defined in a
dedicated draft as proposed in Appendix.
2 In order to ensure a lean management and provisioning of single 2 In order to ensure a lean management and provisioning of single
channel interfaces, the management and control plane of both the channel interfaces, the management and control plane of both the
client and DWDM network MUST be aware of the right set of client and DWDM network MUST be aware of the right set of
parameters. Such parameters define the interfaces and the optical parameters. Such parameters define the interfaces and the optical
network and are needed to properly setup the optical connection. network and are needed to properly setup the optical connection.
3 A standard-based northbound API (to network management system) 3 A standard-based northbound API (to network management system)
based on Netconf SHOULD be supported, alternatively SNMP MAY based on Netconf/Restconf SHOULD be supported, alternatively SNMP
be supported too. MAY be supported too.
4 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.
5 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
6 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 two 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. The LMP extension MAY be defined in a draft
as reported in Appendix.
7 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.
8 RSVP-TE SHOULD be used to exchange some relevant parameters 8 RSVP-TE SHOULD be used to exchange some relevant parameters
between the client and the optical node (e.g. the label value), between the client and the optical node (e.g. the label value),
without preventing the network to remain in charge of the optical without preventing the network to remain in charge of the optical
path computation path computation
9 Power monitoring functions at both ends of the DWDM connection 9 Power monitoring functions at both ends of the DWDM connection
MAY 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.
10 In fault cases, the network SHOULD be able to recover wavelengths, 10 In fault cases, the network SHOULD be able to recover wavelengths,
either using pre-defined paths or dynamic re-routing. either using pre-defined paths or dynamic re-routing.
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. Appendix
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:
draft-dharinigert-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-dharini-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-galimbe-ccamp-iv-yang
A YANG model to manage the optical parameters for in a WDM network
8. 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 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 10. Security Considerations
The architecture and solution space in scope of this framework The architecture and solution space in scope of this framework
imposes no additional requirements to the security models already imposes no additional requirements to the security models already
defined in RFC5920 for packet/optical networks using GMPLS, covering defined in RFC5920 for packet/optical networks using GMPLS, covering
also Control Plane and Management interfaces. Respective security also Control Plane and Management interfaces. Respective security
mechanisms of the components and protocols, e.g. LMP security mechanisms of the components and protocols, e.g. LMP security
models, can be applied unchanged. models, can be applied unchanged.
As this framework is focusing on the single operator use case, 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 security concerns can be relaxed to a subset compared to a setup
skipping to change at page 25, line 40 skipping to change at page 26, line 22
providing origin verification, integrity and confidentiality. providing origin verification, integrity and confidentiality.
Additionally, access to Management interfaces can be physically or Additionally, access to Management interfaces can be physically or
logically isolated, by configuring them to be only accessible out-of- logically isolated, by configuring them to be only accessible out-of-
band, through a system that is physically or logically separated from band, through a system that is physically or logically separated from
the rest of the network infrastructure. In case where management the rest of the network infrastructure. In case where management
interfaces are accessible in-band at the client device or within the interfaces are accessible in-band at the client device or within the
optical transport netork domain, filtering or firewalling techniques optical transport netork domain, filtering or firewalling techniques
can be used to restrict unauthorized in-band traffic. Authentication can be used to restrict unauthorized in-band traffic. Authentication
techniques may be additionally used in all cases. techniques may be additionally used in all cases.
10. Contributors 11. Contributors
Arnold Mattheus Arnold Mattheus
Deutsche Telekom Deutsche Telekom
Darmstadt Darmstadt
Germany Germany
email arnold.Mattheus@telekom.de email arnold.Mattheus@telekom.de
Manuel Paul Manuel Paul
Deutsche Telekom Deutsche Telekom
Berlin Berlin
Germany Germany
skipping to change at page 26, line 28 skipping to change at page 27, line 28
Darmstadt Darmstadt
Germany Germany
email j.roese@telekom.de email j.roese@telekom.de
Frank Luennemann Frank Luennemann
Deutsche Telekom Deutsche Telekom
Muenster Muenster
Germany Germany
email Frank.Luennemann@telekom.de email Frank.Luennemann@telekom.de
11. References Dharini Hiremagalur
Juniper
1133 Innovation Way
Sunnyvale - 94089 California
USA
dharinih@juniper.net
11.1. Normative References 12. References
12.1. Normative References
[ITU-T.G.694.1] [ITU-T.G.694.1]
International Telecommunications Union, "Spectral grids International Telecommunications Union, "Spectral grids
for WDM applications: DWDM frequency grid", for WDM applications: DWDM frequency grid",
ITU-T Recommendation G.694.1, Febriary 2012. ITU-T Recommendation G.694.1, Febriary 2012.
[ITU-T.G.698.2] [ITU-T.G.698.2]
International Telecommunications Union, "Amplified International Telecommunications Union, "Amplified
multichannel dense wavelength division multiplexing multichannel dense wavelength division multiplexing
applications with single channel optical interfaces", applications with single channel optical interfaces",
skipping to change at page 28, line 5 skipping to change at page 29, line 12
DOI 10.17487/RFC7689, November 2015, DOI 10.17487/RFC7689, November 2015,
<https://www.rfc-editor.org/info/rfc7689>. <https://www.rfc-editor.org/info/rfc7689>.
[RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O., [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O.,
and D. Ceccarelli, "RSVP-TE Signaling Extensions in and D. Ceccarelli, "RSVP-TE Signaling Extensions in
Support of Flexi-Grid Dense Wavelength Division Support of Flexi-Grid Dense Wavelength Division
Multiplexing (DWDM) Networks", RFC 7792, Multiplexing (DWDM) Networks", RFC 7792,
DOI 10.17487/RFC7792, March 2016, DOI 10.17487/RFC7792, March 2016,
<https://www.rfc-editor.org/info/rfc7792>. <https://www.rfc-editor.org/info/rfc7792>.
11.2. Informative References [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>.
12.2. Informative References
[ITU-T.G.691] [ITU-T.G.691]
ITU-T, "Optical interfaces for single channel STM-64 and ITU-T, "Optical interfaces for single channel STM-64 and
other SDH systems with optical amplifiers", other SDH systems with optical amplifiers",
ITU-T Recommendation ITU-T G.691, 2008. ITU-T Recommendation ITU-T G.691, 2008.
[ITU-T.G.693] [ITU-T.G.693]
ITU-T, "Optical interfaces for intra-office systems", ITU-T, "Optical interfaces for intra-office systems",
ITU-T Recommendation ITU-T G.693, 2009. ITU-T Recommendation ITU-T G.693, 2009.
 End of changes. 46 change blocks. 
101 lines changed or deleted 178 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/