draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-08.txt   draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-09.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 16, 2018 Juniper Expires: June 18, 2018 Juniper
D. Beller D. Beller
Nokia Nokia
G. Galimberti, Ed. G. Galimberti, Ed.
Cisco Cisco
J. Meuric J. Meuric
Orange Orange
December 13, 2017 December 15, 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-08 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-09
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
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 16, 2018. This Internet-Draft will expire on June 18, 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
(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
skipping to change at page 3, line 5 skipping to change at page 3, line 5
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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 28 11.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
The usage of external single channel DWDM interfaces (e.g. in The usage of external single channel DWDM interfaces (e.g. in
routers) connected to a DWDM Network (e.g. router connected to a routers) connected to a DWDM Network (e.g. router connected to a
network of ROADMs and optical amplifiers) adds a further networking network of ROADMs and optical amplifiers) adds a further networking
option for operators but requires an harmonised control and option for operators but requires an harmonised control and
management plane interaction between the 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
skipping to change at page 3, line 45 skipping to change at page 3, line 45
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", "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 While RFC 2119 [RFC2119] describes interpretations of these key words
of protocol specifications and implementations, they are used in this in terms of protocol specifications and implementations, they are
document to describe design requirements for protocol extensions. 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 integrated integrated. The DWDM interface migration from integrated
transponders to third party transponders or colored interfaces change transponders to third party transponders or colored interfaces change
this scenario and introduces a standardized interface at the level of this scenario and introduces a standardized interface at the level of
OCh between the DWDM interface 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-T.G.698.2] allows supporting an
transmitter/receiver pair (of a single vendor or from different optical transmitter/receiver pair (of a single vendor or from
vendors) to provide a single optical channel interface and transport different vendors) to provide a single optical channel interface and
it over an optical network composed of amplifiers, filters, add-drop transport it over an optical network composed of amplifiers, filters,
multiplexers these being possibly from different vendors. Therefore add-drop multiplexers these being possibly from different vendors.
the standard defines the ingress and egress parameters for the Therefore the standard defines the ingress and egress parameters for
optical interfaces at the reference points Ss and Rs. the 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 [ITU-T.G.698.2], which currently include the
features: channel frequency spacing: 50 GHz and wider (defined in following features: channel frequency spacing: 50 GHz and wider
[ITU-T G.694.1]); bit rate of single channel: Up to 10 Gbit/s. (defined in [ITU-T.G.694.1]; bit rate of single channel: Up to 10
Future revisions are expected to include application codes for bit Gbit/s. Future revisions are expected to include application codes
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 [G.805]: the extent of resources which belong Administrative domain [ITU-T.G.805]: the extent of resources which
to a single player such as a network operator, a service provider or belong to a single player such as a network operator, a service
an end-user. Administrative domains of different players do not provider or an end-user. Administrative domains of different players
overlap amongst themselves. do not overlap amongst themselves.
Intra-domain interface (IaDI) [G.872]: A physical interface within an Intra-domain interface (IaDI) [ITU-T.G.872]: A physical interface
administrative domain. within an administrative domain.
Inter-domain interface (IrDI) [G.872]: A physical interface that Inter-domain interface (IrDI) [ITU-T.G.872]: A physical interface
represents the boundary between two administrative domains. that represents the boundary between two administrative domains.
Management Plane [G.8081]: The management plane performs management Management Plane [ITU-T.G.8081],: The management plane performs
functions for the transport plane, the control plane and the system management functions for the transport plane, the control plane and
as a whole. It also provides coordination between all the planes. the system as a whole. It also provides coordination between all the
The following management functional areas are performed in the planes. The following management functional areas are performed in
management plane: performance management, fault management, the management plane: performance management, fault management,
configuration management, accounting management and security configuration management, accounting management and security
management. management.
Control Plane [G.8081]: Through signaling, the control plane sets up Control Plane [ITU-T.G.8081]: Through signaling, the control plane
and releases connections, may restore a connection in case of a sets up and releases connections, may restore a connection in case of
failure, and also performs other functions (e.g., neighbor discovery, a failure, and also performs other functions (e.g., neighbor
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.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 Add
Drop Multiplexers (ROADM) Line Amplifiers and the the fibers Drop Multiplexers (ROADM) Line Amplifiers and the the fibers
connecting them. 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-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
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,
skipping to change at page 6, line 4 skipping to change at page 6, line 4
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], etc.
IrDI IaDI IrDI IaDI
| | | |
. . . .
| +----------------------------|----+ | +----------------------------|----+
. | + WDM Domain + . | . | + WDM Domain + . |
| | |\ /| | | | | |\ /| | |
+------+ . | | \ |\ / | . | +------+ +------+ . | | \ |\ / | . | +------+
| TX/ |-->--+---+--T/-|OM|----|/-------|OD|--+-\T-+---->--| RX/ | | TX/ |-->--+---+--T/-|OM|----|/-------|OD|--+-\T-+---->--| RX/ |
| RX |--<--+---+--T/-| |----- /|-----| |--.-\T-+----<--| TX | | RX |--<--+---+--T/-| |----- /|-----| |--.-\T-+----<--| TX |
skipping to change at page 6, line 35 skipping to change at page 6, line 35
OD = Optical Demux OD = Optical Demux
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 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 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.
skipping to change at page 12, 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
[RFC4209] should be used. This extension of LMP may be used between RFC 4209 [RFC4209] should be used. This extension of LMP may be used
a peer node and an adjacent optical network node as depicted in between a peer node and an adjacent optical network node as depicted
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 must be added to the protocol. The use of LMP assumes that some form
of a control channel exists between the client node and the WDM of a control channel exists between the client node and the WDM
equipment. This may be a dedicated lambda or an Ethernet Link. 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. [RFC7689] for plane protocols have been extended for WSON, e.g. RFC 7689 [RFC7689]
fixed grid signal and for flexi-grid [RFC7792]. One important aspect ) for fixed grid signal and for flexi-grid RFC 7792 [RFC7792] ). One
of the Black Link [G.698.2] is the fact that it includes the important aspect of the Black Link [ITU-T.G.698.2] is the fact that
wavelength that is supported by the given link. Therefore, the link it includes the wavelength that is supported by the given link.
can logically be considered as a fiber that is transparent only for a Therefore, the link can logically be considered as a fiber that is
single wavelength. In other words, the wavelength becomes a transparent only for a single wavelength. In other words, the
characteristic of the link itself. wavelength becomes a 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 13, line 50 skipping to change at page 13, line 50
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
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 RFC
[RFC4209] and [RFC4204] which provides the necessary protocol 4209 [RFC4209] and RFC 4204 [RFC4204] which provides the necessary
framework to exchange those characteristics between client and Black protocol framework to exchange those characteristics between client
Link. LMP-WDM is not intended for exchanging routing or signaling and Black Link. LMP-WDM is not intended for exchanging routing or
information nor to provision the lambda in the transceiver but signaling information nor to provision the lambda in the transceiver
covers: but 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 covering the parameter sets (e.g. application Extensions to LMP covering the parameter sets (e.g. application
skipping to change at page 14, line 30 skipping to change at page 14, line 30
useful to help the management system to do troubleshooting or alarm useful to help the management system to do troubleshooting or alarm
correlation. 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 edge 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. [RFC4208] defines the GMPLS instance that runs among the core nodes. RFC 4208 [RFC4208] defines
UNI that can be used between edge and core node. In case of the GMPLS UNI that can be used between edge and core node. In case
integrated interfaces deployment additional functionalities are of 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. Using RSVP-TE could be used for the signalling and wavelength path. Using RSVP-TE could be used for the signalling and
the 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 on the configured optical interface to exchange information on the configured optical interface
within the edge node 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 [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,
etc. Depending on where the information is available, compatibility etc. Depending on where the information is available, compatibility
check may either happen before signaling, when the signaling reaches check may either happen before signaling, when the signaling reaches
the optical network (e.g. at path computation time), or in the tail the optical network (e.g. at path computation time), or in the tail
end node. An extended version of LMP is needed to exchange this end node. An extended version of LMP is needed to exchange this
information in case a. above, and to RSVP-TE as well in b. It would information in case a. above, and to RSVP-TE as well in b. It would
skipping to change at page 16, line 48 skipping to change at page 16, line 48
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 path 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 [ITU-T.G.698.2] defines a single channel optical interface for DWDM
that allows interconnecting network-external optical transponders systems that allows interconnecting network-external optical
across a DWDM network. The optical transponders are external to the transponders across a DWDM network. The optical transponders are
DWDM network. This so-called 'Black Link' approach illustrated in external to the DWDM network. This so-called 'Black Link' approach
Fig. 5-1 of G.698.2 and a copy of this figure is provided below in illustrated in Fig. 5-1 of [ITU-T.G.698.2] and a copy of this figure
Figure 5. The single channel fiber link between the Ss/Rs reference is provided below in Figure 5. The single channel fiber link between
points and the ingress/egress port of the network element on the the Ss/Rs reference points and the ingress/egress port of the network
domain boundary of the DWDM network (DWDM border NE) is called access element on the domain boundary of the DWDM network (DWDM border NE)
link. Based on the definition in G.698.2 it is part of the DWDM is called access link. Based on the definition in [ITU-T.G.698.2] it
network. The access link is typically realized as a passive fiber is part of the DWDM network. The access link is typically realized
link that has a specific optical attenuation (insertion loss). As as a passive fiber link that has a specific optical attenuation
the access link is an integral part of the DWDM network, it is (insertion loss). As the access link is an integral part of the DWDM
desirable to monitor its attenuation. Therefore, it is useful to network, it is desirable to monitor its attenuation. Therefore, it
detect an increase of the access link attenuation, for example, when is useful to detect an increase of the access link attenuation, for
the access link fiber has been disconnected and reconnected example, when the access link fiber has been disconnected and
(maintenance) and a bad patch panel connection (connector) resulted reconnected (maintenance) and a bad patch panel connection
in a significantly higher access link attenuation (loss of signal in (connector) resulted in a significantly higher access link
the extreme case of an open connector or a fiber cut). In the attenuation (loss of signal in the extreme case of an open connector
following section, two use cases are presented and discussed: or a fiber cut). In the 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
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.
Data plane interoperability as defined for example in [ITU.G698.2] is Data plane interoperability as defined for example in [ITU-T.G.698.2]
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 standardized procedure to setup an optical connection MUST
be defined and implemented in DWDM and client devices be defined and implemented in DWDM and client devices
(containing the single channel optical interface). (containing the single channel optical interface).
2 In order to ensure a lean management and provisioning of single 2 In order to ensure a lean management and provisioning of single
skipping to change at page 26, line 32 skipping to change at page 26, line 32
Frank Luennemann Frank Luennemann
Deutsche Telekom Deutsche Telekom
Muenster Muenster
Germany Germany
email Frank.Luennemann@telekom.de email Frank.Luennemann@telekom.de
11. References 11. References
11.1. Normative References 11.1. Normative References
[ITU.G.872] [ITU-T.G.694.1]
International Telecommunications Union, "Architecture of International Telecommunications Union, "Spectral grids
optical transport networks", ITU-T Recommendation G.872, for WDM applications: DWDM frequency grid",
November 2001. ITU-T Recommendation G.694.1, Febriary 2012.
[ITU.G698.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",
ITU-T Recommendation G.698.2, November 2009. ITU-T Recommendation G.698.2, November 2009.
[ITU.G709] [ITU-T.G.805]
International Telecommunications Union, "Interface for the International Telecommunications Union, "Spectral grids
Optical Transport Network (OTN)", ITU-T Recommendation for WDM applications: DWDM frequency grid",
G.709, March 2003. ITU-T Recommendation G.805, March 2000.
[ITU-T.G.872]
International Telecommunications Union, "Architecture of
optical transport networks", ITU-T Recommendation G.872,
November 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578,
DOI 10.17487/RFC2578, April 1999,
<https://www.rfc-editor.org/info/rfc2578>.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999,
<https://www.rfc-editor.org/info/rfc2579>.
[RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Conformance Statements for SMIv2",
STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999,
<https://www.rfc-editor.org/info/rfc2580>.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
<https://www.rfc-editor.org/info/rfc2863>.
[RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of [RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of
Managed Objects for the Optical Interface Type", RFC 3591, Managed Objects for the Optical Interface Type", RFC 3591,
DOI 10.17487/RFC3591, September 2003, DOI 10.17487/RFC3591, September 2003,
<https://www.rfc-editor.org/info/rfc3591>. <https://www.rfc-editor.org/info/rfc3591>.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
DOI 10.17487/RFC4204, October 2005, DOI 10.17487/RFC4204, October 2005,
<https://www.rfc-editor.org/info/rfc4204>. <https://www.rfc-editor.org/info/rfc4204>.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, DOI 10.17487/RFC4208, October 2005,
<https://www.rfc-editor.org/info/rfc4208>.
[RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management [RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management
Protocol (LMP) for Dense Wavelength Division Multiplexing Protocol (LMP) for Dense Wavelength Division Multiplexing
(DWDM) Optical Line Systems", RFC 4209, (DWDM) Optical Line Systems", RFC 4209,
DOI 10.17487/RFC4209, October 2005, DOI 10.17487/RFC4209, October 2005,
<https://www.rfc-editor.org/info/rfc4209>. <https://www.rfc-editor.org/info/rfc4209>.
[RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for [RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G.,
Lambda-Switch-Capable (LSC) Label Switching Routers", and H. Harai, "Signaling Extensions for Wavelength
RFC 6205, DOI 10.17487/RFC6205, March 2011, Switched Optical Networks", RFC 7689,
<https://www.rfc-editor.org/info/rfc6205>. DOI 10.17487/RFC7689, November 2015,
<https://www.rfc-editor.org/info/rfc7689>.
11.2. Informative References [RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O.,
and D. Ceccarelli, "RSVP-TE Signaling Extensions in
Support of Flexi-Grid Dense Wavelength Division
Multiplexing (DWDM) Networks", RFC 7792,
DOI 10.17487/RFC7792, March 2016,
<https://www.rfc-editor.org/info/rfc7792>.
[DWDM-interface-MIB] 11.2. Informative References
Internet Engineering Task Force, "A SNMP MIB to manage the
DWDM optical interface parameters of DWDM applications",
draft-galimkunze-ccamp-dwdm-if-snmp-mib draft-galimkunze-
ccamp-dwdm-if-snmp-mib, July 2011.
[ITU-TG.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-TG.692] [ITU-T.G.693]
ITU-T, "Transmission media characteristics -
Characteristics of optical components and sub-systems",
ITU-T Recommendation ITU-T G.692, 1998.
[ITU-TG.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.
[ITU-TG.8081] [ITU-T.G.8081]
ITU-T, "Terms and definitions for Automatically Switched ITU-T, "Terms and definitions for Automatically Switched
Optical Networks (ASON)", ITU-T Recommendation G.8081", Optical Networks (ASON)", ITU-T Recommendation G.8081",
ITU-T Recommendation ITU-T G.8081, September 2010. ITU-T Recommendation ITU-T G.8081, September 2010.
[ITU-TG.957] [ITU-T.G.957]
ITU-T, "Optical interfaces for equipments and systems ITU-T, "Optical interfaces for equipments and systems
relating to the synchronous digital hierarchy", relating to the synchronous digital hierarchy",
ITU-T Recommendation ITU-T G.957, 2006. ITU-T Recommendation ITU-T G.957, 2006.
[ITU-TG.959.1]
ITU-T, "Optical transport network physical layer
interfaces", ITU-T Recommendation ITU-T G.959.1, 2009.
[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 [RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support
 End of changes. 37 change blocks. 
135 lines changed or deleted 122 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/