draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-12.txt   draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13.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: May 17, 2019 Juniper Expires: January 25, 2020 Juniper
D. Beller D. Beller
Nokia Nokia
G. Galimberti, Ed. G. Galimberti, Ed.
Cisco Cisco
J. Meuric J. Meuric
Orange Orange
November 13, 2018 July 24, 2019
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-12 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-13
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 7 skipping to change at page 2, line 7
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 May 17, 2019. This Internet-Draft will expire on January 25, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 42 skipping to change at page 2, line 42
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. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 15 6. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Link Monitoring Use Cases . . . . . . . . . . . . . . . . 16 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 A.1. Optical interface parameter collection . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 A.2. DWDM client - ROADM interconection discovery . . . . . . 21
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 A.3. Service Setup . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 A.4. Link Monitoring Use Cases . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 26 A.4.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 28 A.4.2. Power Control Loop Use Case . . . . . . . . . . . . . 27
Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 29 A.5. Optical Circuit restoration . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 A.6. Multilayer restoration . . . . . . . . . . . . . . . . . 29
Appendix B. Detailed info drafts . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The usage of external single channel Dense Wavelenght Division The usage of external single channel Dense Wavelenght Division
Multiplexing (DWDM) interfaces (e.g. in routers) connected to a DWDM Multiplexing (DWDM) interfaces (e.g. in routers) connected to a DWDM
Network (e.g. router connected to a network of Reconfigurable Optical Network (e.g. router connected to a network of Reconfigurable Optical
Add Drop Multiplexers (ROADM) and optical amplifiers) adds a further Add Drop Multiplexers (ROADM) and optical amplifiers) adds a further
networking option for operators but requires an harmonised control networking option for operators but requires an harmonised control
and management plane interaction between the different network and management plane interaction between the different network
domains. domains.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
parameters of physical point-to-point and ring DWDM applications on parameters of physical point-to-point and ring DWDM applications on
single-mode optical fibres and allows the direct connection of a wide single-mode optical fibres and allows the direct connection of a wide
variety of equipment using a DWDM link, for example variety of equipment using a DWDM link, for example
1. A digital cross-connect with multiple optical interfaces, 1. A digital cross-connect with multiple optical interfaces,
supplied by a different vendor from the line system supplied by a different vendor from the line system
2. Devices as routing, switching or compute nodes, each from a 2. Devices as routing, switching or compute nodes, each from a
different vendor, providing optical line interfaces different vendor, providing optical line interfaces
3. A combination of the above 3. A set of Data Center Equipment and servers
4. A combination of the above
3.1. Comparison of Approaches for Transverse Compatibility 3.1. Comparison of Approaches for Transverse Compatibility
This section describes two ways to achieve transverse compatibility. This section describes two ways to achieve transverse compatibility.
Section 3.1.1 describes the classic model based on well defined Section 3.1.1 describes the classic model based on well defined
inter-domain interfaces. Section 3.1.2 defines a model ensuring inter-domain interfaces. Section 3.1.2 defines a model ensuring
interoperability on the line side of the optical network. interoperability on the line side of the optical network.
3.1.1. Multivendor DWDM Line System with Transponders 3.1.1. Multivendor DWDM Line System with Transponders
skipping to change at page 6, line 47 skipping to change at page 7, line 4
TX/RX = Single channel non-DWDM interfaces TX/RX = Single channel non-DWDM interfaces
T/ = Transponder T/ = Transponder
OM = Optical Mux OM = Optical Mux
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 Intradomanin Interface
specifies the internal parameter set of the optical administrative (IaDI). This interface specifies the internal parameter set of the
domain. In the case of a client DWDM interface deployment this optical administrative domain. In the case of a client DWDM
interface moves into the client device and extends the optical and interface deployment this IaDI moves into the client device and
administrative domain towards the client node. [ITU-T.G.698.2] for extends the optical and administrative domain towards the client
example specifies a set of parameter set for a certain set of node. [ITU-T.G.698.2] for example specifies a set of parameter set
applications. for a certain set of applications, see Section 3.1.2.
This document elaborates only the IaDI (Intra Domain Interface) as This document elaborates only the IaDI (Intra Domain Interface) as
shown in Figure 1 as DWDM transversely compatible and multi-vendor shown in Figure 1 as DWDM transversely compatible and multi-vendor
interface within one administrative domain controlled by the network interface within one administrative domain controlled by the network
operator. operator.
SNMP/Simple Management Interface (SMI), NETCONF/RESTCONF and Link SNMP/Simple Management Interface (SMI), NETCONF/RESTCONF and Link
Management Protocol (LMP) TLV to support the direct exchange of 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.
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
would need to be added to the protocol. The use of LMP assumes that is addressed by draft-ietf-ccamp-dwdm-if-lmp extending the RFC 4209
some form of a control channel exists between the client node and the [RFC4209]. The use of LMP assumes that some form of a control
WDM equipment. This may be a dedicated lambda or an Ethernet Link. channel exists between the client node and the WDM equipment. This
may be a dedicated lambda or an Ethernet Link.
4.2. Control Plane Considerations 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 is specific to the wavelength that is supported by the given link. it is specific to the wavelength that is supported by the given link.
Therefore, the link can logically be considered as a fiber that is Therefore, the link can logically be considered as a fiber that is
skipping to change at page 14, line 19 skipping to change at page 14, line 19
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
codes) are needed. Additionally, when client and server side are codes) are needed, see draft-ietf-ccamp-dwdm-if-lmp. Additionally,
managed by different operational entities, the link state may be when client and server side are managed by different operational
useful to help the management system to do troubleshooting or alarm entities, the link state may be useful to help the management system
correlation. to do troubleshooting or alarm correlation.
4.2.1. Considerations Using GMPLS Signaling 4.2.1. Considerations Using GMPLS Signaling
The deployment of single channel optical interfaces is leading to The deployment of single channel optical interfaces is leading to
some functional changes related to the control plane models and has some functional changes related to the control plane models and has
therefore some impact on the existing interfaces especially in the therefore some impact on the existing interfaces especially in the
case of a model where the edge node requests resources from the core case of a model where the edge node requests resources from the core
node and the 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. RFC 4208 [RFC4208] defines instance that runs among the core nodes. RFC 4208 [RFC4208] defines
the GMPLS UNI that can be used between edge and core node. In case the GMPLS UNI that can be used between edge and core node. In case
skipping to change at page 15, line 35 skipping to change at page 15, line 35
b) Due to the bidirectional wavelength path that must be setup, the b) Due to the bidirectional wavelength path that must be setup, the
upstream edge node must include a wavelength value into the RSVP-TE upstream edge node must include a wavelength value into the RSVP-TE
Path message. But in the case of a UNI model the client device may Path message. But in the case of a UNI model the client device may
not have full information about which wavelength must/should be not have full information about which wavelength must/should be
selected, whereas this information must be exchanged between the edge selected, whereas this information must be exchanged between the edge
and the core node. The special value defined in and the core node. The special value defined in
[Network-Assigned-Upstream-Label] allows the optical network to [Network-Assigned-Upstream-Label] allows the optical network to
assign the actual wavelength to be used by the upstream transponder, assign the actual wavelength to be used by the upstream transponder,
which is a simple and efficient solution to this issue. which is a simple and efficient solution to this issue.
5. Use Cases 5. Requirements
As network architectures become more complex, management and
operations, including the the provisioning process, need progress
towards automation. Simplifying and automating the entire management
as well as the network provisioning process while enabling higher
link utilization and faster restoration times are the main targets of
this section.
Supporting network management protocols such as NETCONF [RFC6241] or
RESTCONF [RFC8040] is the base for the communication among EMS/NMS,
centralized controller and network elements. This implies to speficy
the corresponding IETF YANG modules to fully and consistently manage
the feature discussed on this document.
Data plane interoperability as defined for example in [ITU-T.G.698.2]
is a precondition to take full benefit from standardized interfaces
between network and control/management plane.
The following requirements are focusing on the usage of DWDM
interfaces using IETF technologies. Obvisouly, a common set of
solutions must be consistently supported by both the devices hosting
DWDM interfaces and the WDM network (i.e., the WDM line). The
solutions addressing the following requirements will be discussed in
further documents.
1 A YANG data model MUST define the optical parameters to be
exchanged (e.g., power setting) between the network elements and
the management plane so as to configure single channel interfaces
through NETCONF/RESTCONF.
2 LMP MUST allow to convey the relevant optical parameters between
two nodes to correlate neighbor characteristics and identify
common capabilities or compatible ranges between the WDM line and
single channel interfaces.
3 RSVP-TE MUST support the relevant parameters to be exchanged
between the device hosting the DWDM interface and the optical node
(e.g. the label value),
without preventing the network to remain in charge of the optical
path computation.
4 Power monitoring functions at both ends of the DWDM connection
MAY be used to further automate the setup and shutdown process of
the optical interfaces. LMP SHOULD suppport a way to carry
associated measurement from the client devices to the edges of the
WDM network.
5 In fault cases, the network SHOULD be able to recover wavelengths.
RSVP-TE extensions MUST remain compatible with [RFC4873] features.
The Yang modules should mimic a similar level of capability.
6. Gap Analysis
To enable a centralized control function, several gaps in existing
RFCs have been identified:
1 RFC 8343 defines a generic YANG model for interface management.
However, to control DWDM interfaces, an augmentation needs to be
defined which allows to configure DWDM specifics such as wavelength
or FEC-type.
2 RFC 7224 defines iana-if-type YANG modules and needs extension to
include DWDM interfaces.
3 RFC 4204 defines the Link Management Protocol (LMP) to correlate
link properties between two adjacent nodes. Extensions are required
to cover the use cases described such as the correlation between a
Transponder and a ROADM node.
4 RFC 8454 defines an information model for Abstraction and
Control of TE Networks (ACTN). However it does not support
impairment aware path selection or computation.
5 RFC 7823 describes Performance-Based Path Selection for Explicitly
Routed Label Switched Paths (LSPs) Using TE Metric Extensions,
but does not define Metric extensions suitable for Impairment
aware routing in optical transport Networks
6 RFC 7471 in turn defines OSPF Traffic Engineering (TE) Metric
Extensions covering several use cases but lacks Imairment
awareness.
7 RFC 6163 provides a Framework for GMPLS and Path Computation
Element (PCE) Control of Wavelength Switched Optical Networks
(WSONs). While it describes methods for communicating RWA relevant
information, it does not identify such information.
8 Yang Models describing the optical parameter to be used to control
the network ad allow an external controller (like ACTN) to are
missing although are defined by ITU and reported in the
As this framework is focusing on the single operator use case, the
security concerns can be relaxed to a subset compared to a setup
where information is exchanged between external parties and over
external interfaces.
Concerning the access control to Management interfaces, security
issues can be generally addressed by authentication techniques
providing origin verification, integrity and confidentiality.
Additionally, access to Management interfaces can be physically or
logically isolated, by configuring them to be only accessible out-of-
band, through a system that is physically or logically separated from
the rest of the network infrastructure. In case where management
interfaces are accessible in-band at the client device or within the
optical transport network domain, filtering or firewalling techniques
can be used to restrict unauthorized in-band traffic. Authentication
techniques may be additionally used in all cases.
7. Contributors
Arnold Mattheus
Deutsche Telekom
Darmstadt
Germany
email arnold.Mattheus@telekom.de
Manuel Paul
Deutsche Telekom
Berlin
Germany
email Manuel.Paul@telekom.de
Josef Roese
Deutsche Telekom
Darmstadt
Germany
email j.roese@telekom.de
Frank Luennemann
Deutsche Telekom
Muenster
Germany
email Frank.Luennemann@telekom.de
Dharini Hiremagalur
Juniper
1133 Innovation Way
Sunnyvale - 94089 California
USA
dharinih@juniper.net
8. References
8.1. Normative References
[ITU-T.G.694.1]
International Telecommunications Union, "Spectral grids
for WDM applications: DWDM frequency grid",
ITU-T Recommendation G.694.1, Febriary 2012.
[ITU-T.G.698.2]
International Telecommunications Union, "Amplified
multichannel dense wavelength division multiplexing
applications with single channel optical interfaces",
ITU-T Recommendation G.698.2, November 2009.
[ITU-T.G.805]
International Telecommunications Union, "Spectral grids
for WDM applications: DWDM frequency grid",
ITU-T Recommendation G.805, March 2000.
[ITU-T.G.872]
International Telecommunications Union, "Architecture of
optical transport networks", ITU-T Recommendation G.872,
November 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of
Managed Objects for the Optical Interface Type", RFC 3591,
DOI 10.17487/RFC3591, September 2003,
<https://www.rfc-editor.org/info/rfc3591>.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
DOI 10.17487/RFC4204, October 2005,
<https://www.rfc-editor.org/info/rfc4204>.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, DOI 10.17487/RFC4208, October 2005,
<https://www.rfc-editor.org/info/rfc4208>.
[RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management
Protocol (LMP) for Dense Wavelength Division Multiplexing
(DWDM) Optical Line Systems", RFC 4209,
DOI 10.17487/RFC4209, October 2005,
<https://www.rfc-editor.org/info/rfc4209>.
[RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G.,
and H. Harai, "Signaling Extensions for Wavelength
Switched Optical Networks", RFC 7689,
DOI 10.17487/RFC7689, November 2015,
<https://www.rfc-editor.org/info/rfc7689>.
[RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O.,
and D. Ceccarelli, "RSVP-TE Signaling Extensions in
Support of Flexi-Grid Dense Wavelength Division
Multiplexing (DWDM) Networks", RFC 7792,
DOI 10.17487/RFC7792, March 2016,
<https://www.rfc-editor.org/info/rfc7792>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[ITU-T.G.691]
ITU-T, "Optical interfaces for single channel STM-64 and
other SDH systems with optical amplifiers",
ITU-T Recommendation ITU-T G.691, 2008.
[ITU-T.G.693]
ITU-T, "Optical interfaces for intra-office systems",
ITU-T Recommendation ITU-T G.693, 2009.
[ITU-T.G.8081]
ITU-T, "Terms and definitions for Automatically Switched
Optical Networks (ASON)", ITU-T Recommendation G.8081",
ITU-T Recommendation ITU-T G.8081, September 2010.
[ITU-T.G.957]
ITU-T, "Optical interfaces for equipments and systems
relating to the synchronous digital hierarchy",
ITU-T Recommendation ITU-T G.957, 2006.
[Network-Assigned-Upstream-Label]
Internet Engineering Task Force, "Generalized Multi-
Protocol Label Switching (GMPLS) Resource reSerVation
Protocol with Traffic Engineering (RSVP- TE) mechanism
that enables the network to assign an upstream label for a
bidirectional LSP", draft-ietf-teas-network-assigned-
upstream-label draft-ietf-teas-network-assigned-upstream-
label, June 2017.
[RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support
Operation of MPLS-TE over GMPLS Networks", RFC 5146,
DOI 10.17487/RFC5146, March 2008,
<https://www.rfc-editor.org/info/rfc5146>.
Appendix A. Use Cases
A comparison with the traditional operation scenarios provides an A comparison with the traditional operation scenarios provides an
insight of similarities and distinctions in operation and management insight of similarities and distinctions in operation and management
of DWDM interfaces. The following use cases provide an overview of DWDM interfaces. The following use cases provide an overview
about operation and maintenance processes. about operation and maintenance processes.
5.1. Service Setup A.1. Optical interface parameter collection
It is necessary to identify the Optical interface characteristics and
setting in order to properly calculate the ent to end path and match
the Head End interface against the Tail End interface compatibility.
The optical parameters may have multiple possible values that the
Controller (SDN or GMPLS) can use and select for the best network
optimisation.
A.2. DWDM client - ROADM interconection discovery
Being the the DWDM port and ROADM port belonging to different domains
and Network Elements, the interconnection between them is not
embedded in the Optical Nodes and can not be shared to the EMS and
the Controller. The Controller needs then to retrieve the
connectivity using data coming from the two domains correlating them
to discover the relationship. The methods to discover the
interconnection can be LMP, LLDP, installation provisioning or any
other mechanism checking using the light transmitted by the DWDM
transmitter and detecter by the ROAMD port photodiode. This use case
is fundamental to build the interconnections between the DWDM and
Client layer (e.g. Routers) and calculate the multilayer network
topology.
A.3. Service Setup
It is necessary to differentiate between different operational issues It is necessary to differentiate between different operational issues
for setting up a light path (a DWDM connection is specific in having for setting up a light path (a DWDM connection is specific in having
defined maximum impairments) within an operational network. defined maximum impairments) within an operational network.
The first step is to determine if transceivers located at different The first step is to determine if transceivers located at different
end-points are interoperable, i.e. support a common set of end-points are interoperable, i.e. support a common set of
operational parameters. In this step it is required to determine operational parameters. In this step it is required to determine
transceiver capabilities in a way to be able to correlate them for transceiver capabilities in a way to be able to correlate them for
interoperability purposes. Such parameters include modulation interoperability purposes. Such parameters include modulation
skipping to change at page 16, line 36 skipping to change at page 22, line 30
In a fourth step, optical monitoring is activated in the WDM network In a fourth step, optical monitoring is activated in the WDM network
in order to monitor the status of the connection. The monitor in order to monitor the status of the connection. The monitor
functions of the optical interfaces at the terminals are also functions of the optical interfaces at the terminals are also
activated in order to monitor the end to end connection. activated in order to monitor the end to end connection.
Furthermore it should be possible to automate this step. After Furthermore it should be possible to automate this step. After
connecting the client device to the neighbor control plane-enabled connecting the client device to the neighbor control plane-enabled
transport node, a control adjacency may be automatically established, transport node, a control adjacency may be automatically established,
e.g. using LMP. e.g. using LMP.
5.2. Link Monitoring Use Cases A.4. Link Monitoring Use Cases
The use cases described below are assuming that power monitoring The use cases described below are assuming that power monitoring
functions are available in the ingress and egress network element of functions are available in the ingress and egress network element of
the DWDM network, respectively. By performing link property the DWDM network, respectively. By performing link property
correlation it would be beneficial to include the current transmit correlation it would be beneficial to include the current transmit
power value at reference point Ss and the current received power power value at reference point Ss and the current received power
value at reference point Rs. For example if the Client transmitter value at reference point Rs. For example if the Client transmitter
power has a value of 0dBm and the ROADM interface measured power is power has a value of 0dBm and the ROADM interface measured power is
-6dBm the fiber patch cord connecting the two nodes may be pinched or -6dBm the fiber patch cord connecting the two nodes may be pinched or
the connectors are dirty. As discussed before, the actual path or the connectors are dirty. As discussed before, the actual path or
skipping to change at page 19, line 5 skipping to change at page 25, line 5
configured threshold (t [dB]): configured threshold (t [dB]):
- P(in) < P(Tx) - a(Tx) - t (Tx direction) - P(in) < P(Tx) - a(Tx) - t (Tx direction)
- P(Rx) < P(out) - a(Rx) - t (Rx direction) - P(Rx) < P(out) - a(Rx) - t (Rx direction)
- a(Tx) =| a(Rx) - a(Tx) =| a(Rx)
Alarms and events can be shared between Client and Network Alarms and events can be shared between Client and Network
via LMP. via LMP.
Figure 5: Access Link Power Monitoring Figure 5: Access Link Power Monitoring
5.2.1. Pure Access Link (AL) Monitoring Use Case A.4.1. Pure Access Link (AL) Monitoring Use Case
Figure 6 illustrates the access link monitoring use case and the Figure 6 illustrates the access link monitoring use case and the
different physical properties involved that are defined below: different physical properties involved that are defined below:
- Ss, Rs: Single Channel reference points - Ss, Rs: Single Channel reference points
- P(Tx): current optical output power of transmitter Tx - P(Tx): current optical output power of transmitter Tx
- a(Tx): access link attenuation in Tx direction (external - a(Tx): access link attenuation in Tx direction (external
transponder point of view) transponder point of view)
- P(in): measured current optical input power at the input port - P(in): measured current optical input power at the input port
of border DWDM NE of border DWDM NE
skipping to change at page 21, line 6 skipping to change at page 27, line 6
An alarm shall be raised if P(in) or P(Rx) drops below a An alarm shall be raised if P(in) or P(Rx) drops below a
configured threshold (t [dB]): configured threshold (t [dB]):
- P(in) < P(Tx) - a(Tx) - t (Tx direction) - P(in) < P(Tx) - a(Tx) - t (Tx direction)
- P(Rx) < P(out) - a(Rx) - t (Rx direction) - P(Rx) < P(out) - a(Rx) - t (Rx direction)
- a(Tx) = a(Rx) - a(Tx) = a(Rx)
Alarms and events can be shared between Client and Network Alarms and events can be shared between Client and Network
via LMP according to [RFC4204] and [RFC4209] via LMP according to [RFC4204] and [RFC4209]
Figure 6: Extended LMP Model Figure 6: Extended LMP Model
5.2.2. Power Control Loop Use Case A.4.2. Power Control Loop Use Case
This use case is based on the access link monitoring as This use case is based on the access link monitoring as
described above. In addition, the border NE is running a power described above. In addition, the border NE is running a power
control application that is capable to control the optical output control application that is capable to control the optical output
power of the single channel tributary signal at the output port power of the single channel tributary signal at the output port
of the border DWDM NE (towards the external receiver Rx) and the of the border DWDM NE (towards the external receiver Rx) and the
optical output power of the single channel tributary signal at optical output power of the single channel tributary signal at
the external transmitter Tx within their known operating range. the external transmitter Tx within their known operating range.
The time scale of this control loop is typically relatively slow The time scale of this control loop is typically relatively slow
(e.g. some 10s or minutes) because the access link attenuation (e.g. some 10s or minutes) because the access link attenuation
skipping to change at page 23, line 5 skipping to change at page 29, line 5
| ROADM | | ROADM |
+--------------------------+ +--------------------------+
Figure 7: Power control loop Figure 7: Power control loop
- The power control loop in transponders and ROADMs controls - The power control loop in transponders and ROADMs controls
the Variable Optical Attenuators (VOA) to adjust the proper the Variable Optical Attenuators (VOA) to adjust the proper
power in base of the ROADM and Receiver characteristics and power in base of the ROADM and Receiver characteristics and
the Access Link attenuation the Access Link attenuation
6. Requirements A.5. Optical Circuit restoration
Even if network architectures becomes more complex, management and
operation as well as the provisioning process should have a higher
degree of automation or should be fully automated. Simplifying and
automating the entire management and provisioning process of the
network in combination with a higher link utilization and faster
restoration times will be the major requirements that have been
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]
is a precondition to take full benefit from standardized interfaces
between network and control/management plane.
The following requirements are focusing on the usage of DWDM
interfaces.
1 A procedure to setup an optical connection MUST be defined and
implemented in DWDM and client devices (containing the single
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
channel interfaces, the management and control plane of both the
client and DWDM network MUST be aware of the right set of
parameters. Such parameters define the interfaces and the optical
network and are needed to properly setup the optical connection.
3 A standard-based northbound API (to network management system)
based on NETCONF/RESTCONF SHOULD be supported, alternatively SNMP
MAY be supported too.
4 A standard-based data model for single channel interfaces MUST be
supported to exchange optical parameters with control/management
plane.
5 NETCONF SHOULD be used also for configuration of the single
channel interfaces including the power setting
6 LMP SHOULD be extended and used in cases where optical
parameters need to be exchanged between two nodes to correlate
link characteristics and adopt the working mode of the single
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
channel DWDM interface to ensure that the interface works in
the right range.
8 RSVP-TE SHOULD be used to exchange some relevant parameters
between the client and the optical node (e.g. the label value),
without preventing the network to remain in charge of the optical
path computation
9 Power monitoring functions at both ends of the DWDM connection
MAY be used to further automate the setup and shutdown
process of the optical interfaces.
10 In fault cases, the network SHOULD be able to recover wavelengths,
either using pre-defined paths or dynamic re-routing.
11 LMP MAY be used to monitor and observe the access link.
7. Acknowledgements
The authors would like to thank all who supported the work with
fruitful discussions and contributions.
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
The architecture and solution space in scope of this framework
imposes no additional requirements to the security models already
defined in RFC5920 for packet/optical networks using GMPLS, covering
also Control Plane and Management interfaces. Respective security
mechanisms of the components and protocols, e.g. LMP security
models, can be applied unchanged.
As this framework is focusing on the single operator use case, the
security concerns can be relaxed to a subset compared to a setup
where information is exchanged between external parties and over
external interfaces.
Concerning the access control to Management interfaces, security
issues can be generally addressed by authentication techniques
providing origin verification, integrity and confidentiality.
Additionally, access to Management interfaces can be physically or
logically isolated, by configuring them to be only accessible out-of-
band, through a system that is physically or logically separated from
the rest of the network infrastructure. In case where management
interfaces are accessible in-band at the client device or within the
optical transport network domain, filtering or firewalling techniques
can be used to restrict unauthorized in-band traffic. Authentication
techniques may be additionally used in all cases.
10. Contributors
Arnold Mattheus
Deutsche Telekom
Darmstadt
Germany
email arnold.Mattheus@telekom.de
Manuel Paul
Deutsche Telekom
Berlin
Germany
email Manuel.Paul@telekom.de
Josef Roese
Deutsche Telekom
Darmstadt
Germany
email j.roese@telekom.de
Frank Luennemann
Deutsche Telekom
Muenster
Germany
email Frank.Luennemann@telekom.de
Dharini Hiremagalur
Juniper
1133 Innovation Way
Sunnyvale - 94089 California
USA
dharinih@juniper.net
11. References
11.1. Normative References
[ITU-T.G.694.1]
International Telecommunications Union, "Spectral grids
for WDM applications: DWDM frequency grid",
ITU-T Recommendation G.694.1, Febriary 2012.
[ITU-T.G.698.2]
International Telecommunications Union, "Amplified
multichannel dense wavelength division multiplexing
applications with single channel optical interfaces",
ITU-T Recommendation G.698.2, November 2009.
[ITU-T.G.805]
International Telecommunications Union, "Spectral grids
for WDM applications: DWDM frequency grid",
ITU-T Recommendation G.805, March 2000.
[ITU-T.G.872]
International Telecommunications Union, "Architecture of
optical transport networks", ITU-T Recommendation G.872,
November 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of
Managed Objects for the Optical Interface Type", RFC 3591,
DOI 10.17487/RFC3591, September 2003,
<https://www.rfc-editor.org/info/rfc3591>.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
DOI 10.17487/RFC4204, October 2005,
<https://www.rfc-editor.org/info/rfc4204>.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, DOI 10.17487/RFC4208, October 2005,
<https://www.rfc-editor.org/info/rfc4208>.
[RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management
Protocol (LMP) for Dense Wavelength Division Multiplexing
(DWDM) Optical Line Systems", RFC 4209,
DOI 10.17487/RFC4209, October 2005,
<https://www.rfc-editor.org/info/rfc4209>.
[RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G.,
and H. Harai, "Signaling Extensions for Wavelength
Switched Optical Networks", RFC 7689,
DOI 10.17487/RFC7689, November 2015,
<https://www.rfc-editor.org/info/rfc7689>.
[RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O.,
and D. Ceccarelli, "RSVP-TE Signaling Extensions in
Support of Flexi-Grid Dense Wavelength Division
Multiplexing (DWDM) Networks", RFC 7792,
DOI 10.17487/RFC7792, March 2016,
<https://www.rfc-editor.org/info/rfc7792>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References
[ITU-T.G.691]
ITU-T, "Optical interfaces for single channel STM-64 and
other SDH systems with optical amplifiers",
ITU-T Recommendation ITU-T G.691, 2008.
[ITU-T.G.693]
ITU-T, "Optical interfaces for intra-office systems",
ITU-T Recommendation ITU-T G.693, 2009.
[ITU-T.G.8081]
ITU-T, "Terms and definitions for Automatically Switched
Optical Networks (ASON)", ITU-T Recommendation G.8081",
ITU-T Recommendation ITU-T G.8081, September 2010.
[ITU-T.G.957] Upon an network failure (e.g. fiber cut) the Controller or GMPLS can
ITU-T, "Optical interfaces for equipments and systems initiate an Optical Path restoration process. Other than reroute the
relating to the synchronous digital hierarchy", optical path the controller may need to retune the wavelength and
ITU-T Recommendation ITU-T G.957, 2006. modify the DWDM Transceiver working parameters (e.g. FEC, Modulation
Format, etc.). This operation is done in realtime and can benefit of
Netconf/Yang interface or RSVP signallin on the UNI interface.
[Network-Assigned-Upstream-Label] A.6. Multilayer restoration
Internet Engineering Task Force, "Generalized Multi-
Protocol Label Switching (GMPLS) Resource reSerVation
Protocol with Traffic Engineering (RSVP- TE) mechanism
that enables the network to assign an upstream label for a
bidirectional LSP", draft-ietf-teas-network-assigned-
upstream-label draft-ietf-teas-network-assigned-upstream-
label, June 2017.
[RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support A network failure can be due to an DWDM port failure. The Controller
Operation of MPLS-TE over GMPLS Networks", RFC 5146, is the only actor able to fix issue setting a new circuit terminated
DOI 10.17487/RFC5146, March 2008, on a good Client port (GMPLS is not able to make an new path choosing
<https://www.rfc-editor.org/info/rfc5146>. a different end-point). Other than reroute the optical path the
controller may need to provision the wavelength and modify the DWDM
Transceiver working parameters (e.g. FEC, Modulation Format, etc.).
This operation is done in realtime and must be supported by Netconf/
Yang interface.
Appendix A. Appendix Appendix B. Detailed info drafts
In this section are reported some examples and references on the MIB, In this section are reported some examples and references on the MIB,
Yang and LMP usage. The MIB and TLV defining the parameters Yang and LMP usage. The MIB and TLV defining the parameters
described above are reported in the drafts below and are intended as described above are reported in the drafts below and are intended as
informative data: informative data:
draft-dharinigert-ccamp-dwdm-if-lmp
Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for
Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems
to manage the application code of optical interface parameters in to manage the application code of optical interface parameters in
DWDM application DWDM application
draft-ggalimbe-ccamp-flex-if-lmp draft-ggalimbe-ccamp-flex-if-lmp
Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for
Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems
to manage the application code of optical interface parameters in to manage the application code of optical interface parameters in
DWDM application DWDM application
draft-dharini-ccamp-dwdm-if-param-yang draft-ietf-ccamp-dwdm-if-param-yang
A YANG model to manage the optical interface parameters for an A YANG model to manage the optical interface parameters for an
external transponder in a WDM network external transponder in a WDM network
draft-ietf-ccamp-flexigrid-yang draft-ietf-ccamp-flexigrid-yang
YANG data model for Flexi-Grid Optical Networks YANG data model for Flexi-Grid Optical Networks
draft-ietf-ccamp-wson-iv-info
Information Model for Wavelength Switched Optical Networks (WSONs)
with Impairments Validation
draft-ietf-ccamp-wson-iv-encode
Information Encoding for WSON with Impairments Validation
draft-galimbe-ccamp-iv-yang draft-galimbe-ccamp-iv-yang
A YANG model to manage the optical parameters for in a WDM network A YANG model to manage the optical parameters for in a WDM network
NOTE: the above information is defined at the time of publication of NOTE: the above information is defined at the time of publication of
this document and thus subject to change. this document and thus subject to change.
Authors' Addresses Authors' Addresses
Ruediger Kunze (editor) Ruediger Kunze (editor)
Deutsche Telekom Deutsche Telekom
 End of changes. 23 change blocks. 
277 lines changed or deleted 340 lines changed or added

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