draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-00.txt   draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-01.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: October 6, 2016 Juniper Expires: October 8, 2016 Juniper
D. Beller, Ed. D. Beller, Ed.
ALU Nokia
G. Galimberti, Ed. G. Galimberti, Ed.
Cisco Cisco
April 4, 2016 April 6, 2016
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-00 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-01
Abstract Abstract
To ensure an efficient data transport, meeting the requirements To ensure an efficient data transport, meeting the requirements
requested by today's IP-services the control and management of DWDM requested by today's IP-services the control and management of DWDM
interfaces is a precondition for enhanced multilayer networking and interfaces is a precondition for enhanced multilayer networking and
for an further automation of network provisioning and operation. for an further automation of network provisioning and operation.
This document describes use cases and requirements for the control This document describes use cases and requirements for the control
and management of optical interfaces parameters according to and management of optical interfaces parameters according to
different types of single channel DMDM interfaces. The focus is on different types of single channel DMDM interfaces. The focus is on
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 October 6, 2016. This Internet-Draft will expire on October 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 2, line 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4
3. Solution Space Client DWDM interface . . . . . . . . . . . . 5 3. Solution Space Client DWDM interface . . . . . . . . . . . . 5
3.1. Comparison of approaches for transverse compatibility . . 6 3.1. Comparison of approaches for transverse compatibility . . 6
3.1.1. Multivendor DWDM line system with transponders . . . 6 3.1.1. Multivendor DWDM line system with transponders . . . 6
3.1.2. Black Link Deployments . . . . . . . . . . . . . . . 8 3.1.2. Integrated single channel DWDM deployments on the
4. Solutions for managing and controlling the optical interface 10 client site . . . . . . . . . . . . . . . . . . . . . 8
4.1. Separate Operation and Management Approaches . . . . . . 11 4. Solutions for managing and controlling the optical interface 9
4.1.1. Direct connection to the management system . . . . . 11 4.1. Separate Operation and Management Approaches . . . . . . 10
4.1.2. Direct connection to the DWDM management system . . . 13 4.1.1. Direct connection to the management system . . . . . 10
4.2. Control Plane Considerations . . . . . . . . . . . . . . 15 4.1.2. Direct connection to the DWDM management system . . . 12
4.2.1. Considerations using GMPLS UNI . . . . . . . . . . . 16 4.2. Control Plane Considerations . . . . . . . . . . . . . . 14
5. Operational aspects using IUT-T G.698.2 specified single 4.2.1. Considerations using GMPLS UNI . . . . . . . . . . . 15
channel DWDM interfaces . . . . . . . . . . . . . . . . . . . 17 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Bringing into service . . . . . . . . . . . . . . . . . . 17 5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 16
5.2. LMP Use Cases . . . . . . . . . . . . . . . . . . . . . . 18 5.2. link monitoring Use Cases . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 24
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 27 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
The usage of the Colored interfaces in the Client Nodes connected to The usage of the single channel DWDM interfaces in client nodes (e.g.
a DWDM Network (which include ROADMs and optical amplifiers) adds routers) connected to a DWDM Network (which include ROADMs and
further networking option for operators opening to new scenarios and optical amplifiers) adds a further networking option for operators
requiring more control/management plane integration. opening to new scenarios and requiring more control/management plane
integration.
Carriers deploy their networks today as a combination of transport Carriers deploy their networks today as a combination of transport
and packet infrastructures to ensure high availability and flexible and packet infrastructures to ensure high availability and flexible
data transport. Both network technologies are usually managed by data transport. Both network technologies are usually managed by
different operational units using different management concepts. different operational units using different management concepts.
This is the status quo in many carrier networks today. In the case This is the status quo in many carrier networks today. In the case
of a black link deployment, where the optical transport interface of deployments, where the optical transport interface moves into the
moves into the client device (e.g. , router), it is necessary to client device (e.g. , router), it is necessary to coordinate the
coordinate the management of the optical interface at the client management of the optical interface at the client domain with the
domain with the optical transport domain. There are different levels optical transport domain. There are different levels of
of coordination, which are specified in this framework. coordination, which are specified in this framework.
The objective of this document is to provide a framework that The objective of this document is to provide a framework that
describes the solution space for the control and management of single describes the solution space for the control and management of single
channel interfaces and give use cases on how to manage the solutions. channel interfaces and give use cases on how to manage the solutions.
In particular, it examines topological elements and related network In particular, it examines topological elements and related network
management measures. From an architectural point of view, the management measures. From an architectural point of view, the
network can be consideres as a black link, that is a set of pre- network can be considered as a set of pre- configured/qualified
configured/qualified unidirectional, single-fiber, network unidirectional, single-fiber, network connections between reference
connections between the G.698.2 reference points S and R. The points S and R shown in figure 2. The optical transport network is
optical transport network is managed and controlled in order to managed and controlled in order to provide optical connections at the
provide Oprical Connections at the intended centre frequencies and intended centre frequencies and the optical interfaces are managed
the optical interfaces are managed and controlled to generate signals and controlled to generate signals of the intended centre frequencies
of the intended centre frequencies and further parameters as and further parameters as specified for example in ITU-T
specified in ITU-T Recommendations G.698.2 and G.798. The Management Recommendations G.698.2 and G.798. The management or control plane
or Control planes of the Client and DWDM network must know the of the client and DWDM network must know the parameters of the
parameters of the Interfaces to properly set the optical link. interfaces to properly set the optical link. This knowledge can be
used furthermore, to support fast fault detection.
Furthermore, support for Fast Fault Detection can benefit from the
solution proposed.
Optical Routing and Wavelength assignment based on WSON is out of Optical routing and wavelength assignment based on WSON is out of
scope although can benefit of the way the optical parameters are scope although can benefit of the way the optical parameters are
exchanged between the Client and the DWDM Network. exchanged between the Client and the DWDM Network.
Additionally, the wavelength ordering process and the process how to Additionally, the wavelength ordering process and the process how to
determine the demand for a new wavelength from A to Z is out of determine the demand for a new wavelength from A to Z is out of
scope. scope.
Note that the Control and Management Planes are two separate entities Note that the Control and Management Planes are two separate entities
that are handling the same information in different ways. This that are handling the same information in different ways. This
document covers management as well as control plane considerations in document covers management as well as control plane considerations in
skipping to change at page 5, line 51 skipping to change at page 5, line 48
equipments using a DWDM link, for example: equipments 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. Multiple optical client devices, each from a different vendor, 2. Multiple optical client devices, each from a different vendor,
supplying one channel each supplying one channel each
3. A combination of the above 3. A combination of the above
Table 1 provides a list of management regarding the configuration of Table 1 provides a list of management tasks regarding the
optical parameters. configuration of optical parameters.
+---------------------------------------+---------+----+----+---+---+ +---------------------------------------+---------+----+----+---+---+
| Task | Domain | a | b | c | d | | Task | Domain | a | b | c | d |
+---------------------------------------+---------+----+----+---+---+ +---------------------------------------+---------+----+----+---+---+
| determination of centre frequency | optical | R | R | R | R | | determination of centre frequency | optical | R | R | R | R |
| configuration of centre frequency at | client | NR | NR | R | R | | configuration of centre frequency at | client | NR | NR | R | R |
| optical IF | | | | | | | optical IF | | | | | |
| path computation of wavelength | optical | NR | NR | R | R | | path computation of wavelength | optical | NR | NR | R | R |
| routing of wavelength | optical | NR | NR | R | R | | routing of wavelength | optical | NR | NR | R | R |
| wavelength setup across optical | optical | ? | ? | R | R | | wavelength setup across optical | optical | ? | ? | R | R |
skipping to change at page 6, line 36 skipping to change at page 6, line 36
management management
Furthermore the following deployment cases will be considered: Furthermore the following deployment cases will be considered:
a. Passive WDM a. Passive WDM
b. P2P WDM systems b. P2P WDM systems
c. WDM systems with OADMs c. WDM systems with OADMs
d. Transparent optical networks supporting specific IPoWDM d. Transparent optical networks supporting specific functions,
functions, nterfaces, protocols etc. nterfaces, protocols etc.
Case a) is added for illustration only, since passive WDM is Case a) is added for illustration only, since passive WDM is
specified in ITU-T Recommendations G.695 and G.698.1. specified in ITU-T Recommendations G.695 and G.698.1.
Case b) and case c)are motivated by the usage of legacy equipment Case b) and case c)are motivated by the usage of legacy equipment
using the traditional connection as described in Figure 1 combined using the traditional connection as described in Figure 1 DWDM
with the BL approach. interface integration on the client side.
3.1. Comparison of approaches for transverse compatibility 3.1. Comparison of approaches for transverse compatibility
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 conversion to appropriate parameters). The optical interfaces can
labelled "single channel non-DWDM interfaces from other vendor(s)"
and "Single channel non DWDM interfaces to/from other vendor(s)" can
then be any short reach standardized optical interface that both then be any short reach standardized optical interface that both
vendors support, such as those found in [ITU-T G.957] [ITU-T G.691], vendors support, such as those found in [ITU-T G.957] [ITU-T G.691],
[ITU-T G.693], [ITU-T G.959.1], etc. [ITU-T G.693], [ITU-T G.959.1], etc.
IrDI IaDI IrDI IaDI
| | | |
. . . .
| +----------------------------|----+ | +----------------------------|----+
. | + WDM Domain + . | . | + WDM Domain + . |
| | |\ /| | | | | |\ /| | |
skipping to change at page 7, line 36 skipping to change at page 7, line 34
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 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 Client DWDM interface deployment this domain. In the case of a client DWDM interface deployment this
interface moves into the client devices 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 administrative domain towards the client node. ITU-T G.698.2 for
specifies the parameter set for a certain set of applications. example specifies the parameter set for a certain set of
applications.
This document elaborates only the IaDI Interface as specified in This document elaborates only the IaDI Interface as shown in Figure 1
ITU-T G.698.2 as transversely compatible and multi-vendor interface as transversely compatible and multi-vendor interface within one
within one administrative domain controlled by the network operator. administrative domain controlled by the network operator.
This administrative domain can contain several vendor domains (vendor
A for the DWDM sub-network, and vendors B1 and B2 at the transmitter
and receiver terminal side).
3.1.2. Black Link Deployments 3.1.2. Integrated single channel DWDM deployments on the client site
In case of a Black Link deployment as shown in Figure 2, through the In case of a deployment as shown in Figure 2, through the use of
use of the single channel DWDM interfaces defined in [ITU.G698.2], single channel DWDM interfaces, multi-vendor interconnection can also
multi-vendor interconnection can also be achieved while removing the be achieved while removing the need for one short reach transmitter
need for one s hort reach transmitter and receiver pair per channel and receiver pair per channel (eliminating the transponders).
(eliminating the transponders).
Figure 2 shows a set of reference points, for the linear "black-link" Figure 2 shows a set of reference points, for single-channel
approach, for single-channel connection (Ss and Rs) between connection (Ss and Rs) between transmitters (Tx) and receivers (Rx).
transmitters (Tx) and receivers (Rx). Here the DWDM network elements Here the DWDM network elements include an optical multiplexer (OM)
include an optical multiplexer (OM) and an optical demultiplexer (OD) and an optical demultiplexer (OD) (which are used as a pair with the
(which are used as a pair with the peer element), one or more optical peer element), one or more optical amplifiers and may also include
amplifiers and may also include one or more OADMs. one or more OADMs.
|==================== 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 |-|>|------|->| OADM |--|------|->| OD |--|-->Rx L2 Tx L2---|->| OM |-|>|------|->| OADM |--|------|->| OD |--|-->Rx L2
skipping to change at page 9, line 44 skipping to change at page 9, line 5
Rs = Reference point at the DWDM network element tributary input Rs = Reference point at the DWDM network element tributary input
Lx = Lambda x Lx = Lambda x
OM = Optical Mux OM = Optical Mux
OD = Optical Demux OD = Optical Demux
OADM = Optical Add Drop Mux OADM = Optical Add Drop Mux
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
In Figure 2, if the administrative domain consists of several domains As shown in Figure 2, the administrative domain may consists of
(e.g. A for a DWDM network, B1 for the DWDM Tx, and B2 for the DWDM several vendor domains. Even a in that case a common north bound
Rx), it is typical that there will be a separate Element Management management interface is required to ensure a consistent management of
Systems (EMS) will be used for each vendor domain (e.g. EMS-a for the entire connection.
domain A, EMS-b1 for domain B1, and EMS-b2 for domain B2). Each EMS
may have a common standard north bound management interface to a
Network Management System (NMS), allowing consistent end-to-end
management of the connection.
To facilitate consistent end-to-end network management, the north The following documents[DWDM-interface-MIB], [YANG], [LMP] define
bound management interface from the EMS to the NMS should be such a protocol- FIX-THE-REFERENCE specific information using SNMP/
consistent (frome a management information point of view) with the SMI, Yang models and LMP TLV to support the direct exchange of
standard protocol-neutral (or protocol-specific) information model information between the client and the network control plane.
used in the EMS south bound management interface to its subtending
NEs (TX and/or RX). The [Interface-MIB] defines such a protocol-
specific information using SNMP/SMI, Yang models and LMP TLV to
support the direct exchange of information between the Client and the
Network control planes.
4. Solutions for managing and controlling the optical interface 4. Solutions for managing and controlling the optical interface
Operation and management of WDM systems is traditionally seen as a Operation and management of WDM systems is traditionally seen as a
homogenous group of tasks that could be carried out best when a homogenous group of tasks that could be carried out best when a
single management system or an umbrella management system is used. single management system or an umbrella 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 administers the wavelengths. that also administers the wavelengths.
Therefore from the operational point of view there are the following Therefore from the operational point of view the following approaches
approaches will be considered to manage and operate optical will be considered to manage and operate optical interfaces.
interfaces.
<vspace>: <vspace>:
1. Separate operation and management of client device and the 1. Separate operation and management of client device and the
transport network transport network whereas the single channel interface of the
client belongs to the administrative domain of the transport
network and will be managed by the transport group. This results
in two different approaches to send information to the management
system
a.Direct link between the client device and the management system a.Direct connection from the client to the management
of the optical network (e.g. EMS, NMS) system,ensuring a management of the single channel of the optical
network (e.g. EMS, NMS)
b.Indirect link to the management system of the optical network b.Indirect connection to the management system of the optical
using a protocol between the client device and the directly network using a protocol (LMP) between the client device and the
connected WDM system node to exchange management information with directly connected WDM system node to exchange management
the optical domain information with the optical domain
2. Common operation and management of client device and the 2. Common operation and management of client device including the
Transport network single channel DWDM part and the Transport network
The first option keeps the status quo in large carrier networks as The first option keeps the status quo in large carrier networks as
mentioned above. In that case it must be ensured that the full FCAPS mentioned above. In that case it must be ensured that the full FCAPS
Management (Fault, Configuration, Accounting, Performance and Management (Fault, Configuration, Accounting, Performance and
Security) capabilities are supported. This means from the management Security) capabilities are supported. This means from the management
staff point of view nothing changes. The transceiver/receiver staff point of view nothing changes. The transceiver/receiver
optical interface will be part of the optical management domain and optical interface will be part of the optical management domain and
will be managed from the transport management staff. will be managed from the transport management staff.
The second solution addresses the case where underlying WDM transport The second solution addresses the case where underlying WDM transport
network is mainly used to interconnect a homogeneous set of client network is mainly used to interconnect a homogeneous set of client
nodes (e.g. IP routers or digital crossconnects). Since the service nodes (e.g. IP routers or digital crossconnects). Since the service
creation and restoration could be done by to higher layers (e.g. creation and restoration could be done by the higher layers (e.g.
IP), this may lead to more efficient network operation and a higher IP), this may lead to an efficient network operation and a higher
level of integration. level of integration.
4.1. Separate Operation and Management Approaches 4.1. Separate Operation and Management Approaches
4.1.1. Direct connection to the management system 4.1.1. Direct connection to the management system
As depicted in Figure 3 (case 1a) one possibility to manage the As depicted in Figure 3 (case 1a) one possibility to manage the
optical interface within the client domain is a direct connection to optical interface within the client domain is a direct connection to
the management system of the optical domain. This ensures the management system of the optical domain. This ensures
manageability as usual. manageability as usual.
skipping to change at page 13, line 12 skipping to change at page 12, line 9
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 standardised way to enable interoperable solutions between in a standardised way to enable interoperable solutions between
different optical interface vendors and vendors of the optical different optical interface vendors and vendors of the optical
network management application. RFC 3591 [RFC3591] defines managed network management application. RFC 3591 [RFC3591] defines managed
objects for the optical interface type but needs further extension to objects for the optical interface type but needs further extension to
cover the optical parameters required by this framework document. cover the optical parameters required by this framework document.
Therefore an extension to this MIB for the optical interface has been Therefore an extension to this MIB for the optical interface has been
drafted in [Black-Link-MIB]. In that case SNMP is used to exchange drafted in [DWDM-interface-MIB]. SNMP is used to read parameters and
data between the client device and the management system of the WDM get notifications and alarms, netconf and Yang models are needed to
domain. Yang models are as well needed to enable and SDN controller easily provision the interface with the right parameter set as
to easily read/provision the interfaces parameters. described in [YANG]
Note that a software update of the optical interface components of Note that a software update of the optical interface components of
the client nodes must not lead obligatory to an update of the the client nodes must not lead obligatory to an update of the
software of the EMS and vice versa. software of the EMS and vice versa.
4.1.2. Direct connection to the DWDM management system 4.1.2. Direct connection to the DWDM management system
The alternative as shown in Figure 4 can be used in cases where a An alternative as shown in Figure 4 can be used in cases where a more
more integrated relationship between transport node (e.g. OM or OD) integrated relationship between transport node (e.g. OM or OD) and
and client device is aspired. In that case a combination of control client device is aspired. In that case a combination of control
plane features and manual management will be used. plane features and manual management will be used.
+-----+ +-----+
| NMS | | NMS |
|_____| |_____|
/_____/ /_____/
| |
| |
|
+---+---+ +---+---+
| EMS | | EMS |
| | | |
+-------+ +-------+
| MI SNMP or Yang | MI SNMP or Yang
| |
|
LMP +------+-----------------------+ LMP +------+-----------------------+
+------------+---+ +| + | +------------+---+ +| + |
| | | |\ /| | | | | |\ /| |
+---+--+ | +-+ \ |\ / | | +------+ +---+--+ | +-+ \ |\ / | | +------+
| CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL | | CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL |
| |-/C------+--- -| |----- /|-----| |----+-------/C-| | | |-/C------+--- -| |----- /|-----| |----+-------/C-| |
+------+ | | / \| \ | | +------+ +------+ | | / \| \ | | +------+
| |/ \| | | |/ \| |
| + + | | + + |
+------------------------------+ +------------------------------+
skipping to change at page 14, line 46 skipping to change at page 13, line 44
OM = Optical Mux OM = Optical Mux
OD = Optical Demux OD = Optical Demux
EMS= Element Management System EMS= Element Management System
MI= Management Interface MI= Management Interface
Figure 4: Direct connection between peer node and first optical Figure 4: Direct connection between peer node and first optical
network node network node
For information exchange between the client node and the direct For information exchange between the client node and the direct
connected node of the optical transport network LMP as specified in connected node of the optical transport network LMP as specified in
RFC 4209 [RFC4209] can (should) be used. This extension of LMP may RFC 4209 [RFC4209] should be used. This extension of LMP may be used
be used between a peer node and an adjacent optical network node as between a peer node and an adjacent optical network node as depicted
depicted in Figure 4. in Figure 4.
The LMP based on RFC 4209 does not yet support the transmission of The LMP based on RFC 4209 does not yet support the transmission of
configuration data (information). This functionality has to be added configuration data (information). This functionality must be added
to the existing extensions of the protocol. The use of LMP-WDM to the existing extensions of the protocol. The use of LMP-WDM
assumes that some form of a control channel exists between the client assumes that some form of a control channel exists between the client
node and the WDM equipment. This may be a dedicated lambda, an node and the WDM equipment. This may be a dedicated lambda, an
Ethernet Link, or other signaling communication channel (SCC or Ethernet Link, or other signaling communication channel (SCC or
IPCC). IPCC).
4.2. Control Plane Considerations 4.2. Control Plane Considerations
The concept of black link equally applies to management and control The concept of integrated single channel DWDM interfaces equally
plane mechanisms. The general GMPLS control Plane for wavelength applies to management and control plane mechanisms. The general
switched optical networks is work under definition in the scope of GMPLS control plane for wavelength switched optical networks is work
WSON.One important aspect of the BL is the fact that it includes the under definition in the scope of WSON. One important aspect of the
wavelength that is supported by the given link. Thus a BL can BL is the fact that it includes the wavelength that is supported by
logically be considered as a fiber that is transparent only for a the given link. Thus a BL can logically be considered as a fiber
single wavelength. In other words, the wavelength becomes a that is transparent only for a single wavelength. In other words,
characteristic of the link itself. Nevertheless the procedure to the wavelength becomes a characteristic of the link itself.
light up the fiber may vary depending on the BL implementation. Nevertheless the procedure to light up the fiber may vary depending
Since the implementation of the BL itself is unknown a priori, on the implementation. Since the implementation is unknown a priori,
different sequences to light up wavelength need to be considered: different sequences to light up a wavelength need to be considered:
1. Transponders first, transponder tuning: The transmitter is 1. Interface first, interface tuning: The transmitter is switched on
switched on and the BL is immediately transparent to its and the link is immediately transparent to its wavelength. This
wavelength. This requires the transmitter to carefully tune requires the transmitter to carefully tune power and frequency
power and frequency not overload the line system or to create not overload the line system or to create transients.
transients.
2. Transponder first, OLS tuning: The transmitter is switched on 2. Interface first, OLS tuning: The transmitter is switched on first
first and can immediately go to the max power allowed since the and can immediately go to the max power allowed since the OLS
OLS performs the power tuning. This leads to an intermediate performs the power tuning. This leads to an intermediate state
state where the receiver does not receive a valid signal while where the receiver does not receive a valid signal while the
the transmitter is sending out one. Alarm suppression mechanisms transmitter is sending out one. Alarm suppression mechanisms
shall be employed to overcome that condition. shall be employed to overcome that condition.
3. OLS first, Transponder 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 it is internal facilities there may be a wavelength to fine-tune it is internal facilities there may be a
period of time where a valid signal is transmitted but the period of time where a valid signal is transmitted but the
receiver is unable to detect it. This equally need to be covered receiver is unable to detect it. This equally need to be covered
by alarm suppression mechanisms. by alarm 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 transponders need to be switched for a given wavelength, then the interfaces need to be switched
on and further power tuning takes place. The sequencing of on and further power tuning takes place. The sequencing of
enabling the link needs to be covered as well. enabling the link needs to be covered as well.
The preferred way to address these in a Control Plane enabled network The preferred way to address these in a Control Plane enabled network
is neighbour discovery including exchange of link characteristics and is neighbour discovery including exchange of link characteristics and
link property correlation. The general mechanisms are covered in link property correlation. The general mechanisms are covered in
RFC4209 [LMP-WDM] and RFC 4204[LMP] which provides the necessary RFC4209 [LMP-WDM] and RFC 4204[LMP] which provides the necessary
protocol framework to exchange those characteristics between client protocol framework to exchange those characteristics between client
and black link. LMP-WDM is not intended for exchanging routing or and black link. LMP-WDM is not intended for exchanging routing or
signalling information but covers: signalling information but covers:
1. Control channel manangement 1. Control channel management
2. Link property correlation 2. Link property correlation
3. Link verification 3. Link verification
4. Fault Manangement 4. Fault management
Extensions to LMP/LMP-WDM covering the code points of the BL Extensions to LMP/LMP-WDM covering the code points of the BL
definition are needed. Additionally when client and server side are definition are needed. Additionally when client and server side are
managed by different operational entities, Link state exchange is managed by different operational entities, Link state exchange is
required to align the management systems. required to align the management systems.
4.2.1. Considerations using GMPLS UNI 4.2.1. Considerations using GMPLS UNI
The deployment of G.698.2 optical interfaces is leading to some The deployment of single channel optical interfaces is leading to
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 an overlay model where the edge node requests resources from case of an overlay model where the edge node requests resources from
the core node and the edges node do not participate in the routing the core node and the edges node do not participate in the routing
protocol instance that runs among the core nodes. RFC 4208 [RFC4208] protocol instance that runs among the core nodes. RFC 4208 [RFC4208]
defines the GMPLS UNI that will be used between edge and core node. defines the GMPLS UNI that will be used between edge and core node.
In case of a black link deployment additional functionalities are In case of integrated interfaces deployment additional
needed to setup a connection. functionalities are needed to setup a connection.
It is necessary to differentiate between topology/signalling It is necessary to differentiate between topology/signalling
information and configuration parameters that are needed to setup a information and configuration parameters that are needed to setup a
wavelength path. RSVP-TE could be used for the signalling and the wavelength path. RSVP-TE could be used for the signalling and the
reservation of the wavelength path. But there are additional reservation of the wavelength path. But there are additional
information needed before RSVP-TE can start the signalling process. information needed before RSVP-TE can start the signalling process.
There are three possibilities to proceed: There are three possibilities to proceed:
a. Using RSVP-TE only for the signalling and LMP as described above a. Using RSVP-TE only for the signalling and LMP as described above
to exchange information to configure the optical interface within to exchange information to configure the optical interface within
skipping to change at page 17, line 4 skipping to change at page 15, line 44
wavelength path. RSVP-TE could be used for the signalling and the wavelength path. RSVP-TE could be used for the signalling and the
reservation of the wavelength path. But there are additional reservation of the wavelength path. But there are additional
information needed before RSVP-TE can start the signalling process. information needed before RSVP-TE can start the signalling process.
There are three possibilities to proceed: There are three possibilities to proceed:
a. Using RSVP-TE only for the signalling and LMP as described above a. Using RSVP-TE only for the signalling and LMP as described above
to exchange information to configure the optical interface within to exchange information to configure the optical interface within
the edge node or the edge node or
b. RSVP-TE will be used to transport additional information b. RSVP-TE will be used to transport additional 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 (overlay will be needed from the optical network to the edge node (overlay will be
transformed to a border-peer model) transformed to a border-peer model)
Furthermore following issues should be addressed: Furthermore following issues should be addressed:
a) The Communication between peering edge nodes using an out of band a) The Communication between peering edge nodes using an out of band
control channel. The two nodes have to exchange their optical control channel. The two nodes have to exchange their optical
capabilities. An extended version of LMP is needed to exchange FEC capabilities. An extended version of LMP is needed to exchange FEC
Modulation scheme,etc. that must be the same. It would be helpful Modulation scheme, etc. that must be the same. It would be helpful
to define some common profiles that will be supported. Only if the to define some common profiles that will be supported. Only if the
profiles match with both interface capabilities it is possible start profiles match with both interface capabilities it is possible start
signalling. signalling.
b) Due to the bidirectional wavelength path that must be setup it is b) Due to the bidirectional wavelength path that must be setup it is
obligatory that the upstream edge node inserts a wavelength value obligatory that the upstream edge node inserts a wavelength value
into the path message for the wavelength path towards the upstream into the path message for the wavelength path towards the upstream
node itself. But in the case of an overlay model the client device node itself. But in the case of an overlay model the client device
may not have full information which wavelength must/should be may not have full information which wavelength must/should be
selectedand this information must be exchanged between the edge and selectedand this information must be exchanged between the edge and
the core node. the core node.
5. Operational aspects using IUT-T G.698.2 specified single channel 5. Use cases
DWDM interfaces
A Comparison of the Black Link with the traditional operation A Comparison with the traditional operation scenarios provides an
scenarios provides an insight of similarities and distinctions in insight of similarities and distinctions in operation and management
operation and management. The following four use cases provide an of single channel optical interfaces. The following use cases
overview about operation and maintenance processes. provide an overview about operation and maintenance processes.
5.1. Bringing into service 5.1. Service Setup
It is necessary to differentiate between two operational issues for It is necessary to differentiate between two operational issues for
setting up a light path (a DWDM connection is specific in having setting up a light path (a DWDM connection is specific in having
defined maximum impairments) within an operational network. The defined maximum impairments) within an operational network. The
first step is the preparation of the connection if no optical signal first step is the preparation of the connection if no optical signal
is applied. Therefore it is necessary to define the path of the is applied. Therefore it is necessary to define the path of the
connection. connection.
The second step is to setup the connection between the Cleint DWDM The second step is to setup the connection between the client DWDM
interface and the ROADM port. This is done using the NMS of the interface and the ROADM port. This is done using the NMS of the
optical transport network. From the operation point of view the task optical transport network. From the operation point of view the task
is similar in a Black Link scenario and in a traditional WDM is similar in a Black Link scenario and in a traditional WDM
environment. The Black Link connection is measured by using BER environment. The Black Link connection is measured by using BER
tester which use optical interfaces according to G.698.2. These tester which use optical interfaces according to G.698.2. These
measurements are carried out in accordance with ITU-T Recommendation measurements are carried out in accordance with [ITU-TG.692]. When
M.xxxx. When needed further Black Link connections for resilience needed further connections for resilience are brought into service in
are brought into service in the same way. the same way.
In addition some other parameters like the Transmit Optical Power, In addition some other parameters like the transmit optical oower,
the Received Optical Power, the Frequency, etc. must be considered. the received optical power, the frequency, etc. must be considered.
If the optical interface moves into a client device some of changes If the optical interface moves into a client device some of changes
from the operational point of view have to be considered. The centre from the operational point of view have to be considered. The centre
frequency of the Optical Channel was determined by the setup process. frequency of the Optical Channel was determined by the setup process.
The optical interfaces at both terminals are set to the centre The optical interfaces at both terminals are set to the centre
frequency before interconnected with the dedicated ports of the WDM frequency before interconnected with the dedicated ports of the WDM
network. Optical monitoring is activated in the WDM network after network. Optical monitoring is activated in the WDM network after
the terminals are interconnected with the dedicated ports in order to the terminals are interconnected with the dedicated ports in order to
monitor the status of the connection. The monitor functions of the monitor the status of the connection. The monitor functions of the
optical interfaces at the terminals are also activated in order to optical interfaces at the terminals are also activated in order to
monitor the end to end connection. monitor the end to end connection.
Furthermore it should be possible to automate this last step. After Furthermore it should be possible to automate this last step. After
connecting the client device towards the first control plane managed connecting the client device towards the first control plane managed
skipping to change at page 18, line 29 skipping to change at page 17, line 23
Furthermore it should be possible to automate this last step. After Furthermore it should be possible to automate this last step. After
connecting the client device towards the first control plane managed connecting the client device towards the first control plane managed
transport node a control connection may e.g. be automatically transport node a control connection may e.g. be automatically
established using LMP to exchange configuration information. established using LMP to exchange configuration information.
If tunable interfaces are used in the scenario it would be possible If tunable interfaces are used in the scenario it would be possible
to define a series of backup wavelength routes for restoration that to define a series of backup wavelength routes for restoration that
could be tested and stored in backup profile. In fault cases this could be tested and stored in backup profile. In fault cases this
wavelength routes can be used to recover the service. wavelength routes can be used to recover the service.
5.2. LMP Use Cases 5.2. link monitoring Use Cases
The use cases described below are assuming that power monitoring The use cases described below are assuming that power monitoring
functions are available in the ingress and egress network element of functions are available in the ingress and egress network element of
the DWDM network, respectively. By performing link property the DWDM network, respectively. By performing link property
correlation it would be beneficial to include the current transmit correlation it would be beneficial to include the current transmit
power value at reference point Ss and the current received power power value at reference point Ss and the current received power
value at reference point Rs. For example if the Client transmitter value at reference point Rs. For example if the Client transmitter
power (OXC1) has a value of 0dBm and the ROADM interface measured power (OXC1) has a value of 0dBm and the ROADM interface measured
power (at OLS1) is -6dBm the fiber patch cord connecting the two power (at OLS1) is -6dBm the fiber patch cord connecting the two
nodes may be pinched or the connectors are dirty. More, the nodes may be pinched or the connectors are dirty. More, the
interface characteristics can be used by the OLS network Control interface characteristics can be used by the OLS network Control
Plane in order to check the Optical Channels feasibility. Finally Plane in order to check the Optical Channels feasibility. Finally
the OXC1 transceivers parameters (Application Code) can be shared the OXC1 transceivers parameters (Application Code) can be shared
with OXC2 using the LMP protocol to verify the Transceivers with OXC2 using the LMP protocol to verify the transceivers
compatibility. The actual route selection of a specific wavelength compatibility. The actual route selection of a specific wavelength
within the allowed set is outside the scope of LMP. In GMPLS, the within the allowed set is outside the scope of LMP. In GMPLS, the
parameter selection (e.g. central frequency) is performed by RSVP-TE. parameter selection (e.g. central frequency) is performed by RSVP-TE.
G.698.2 defines a single channel optical interface for DWDM systems G.698.2 defines a single channel optical interface for DWDM systems
that allows interconnecting network-external optical transponders that allows interconnecting network-external optical transponders
across a DWDM network. The optical transponders are considered to be across a DWDM network. The optical transponders are considered to be
external to the DWDM network. This so-called 'black link' approach external to the DWDM network. This so-called 'black link' approach
illustrated in Figure 5-1 of G.698.2 and a copy of this figure is illustrated in Figure 5-1 of G.698.2 and a copy of this figure is
provided below. The single channel fiber link between the Ss/Rs provided below. The single channel fiber link between the Ss/Rs
skipping to change at page 21, line 5 skipping to change at page 19, line 45
- For AL-R monitoring: P(RX) and a(Rx) must be known - For AL-R monitoring: P(RX) and a(Rx) must be known
An alarm shall be raised if P(in) or P(Rx) drops below a An alarm shall be raised if P(in) or P(Rx) drops below a
configured threshold (t [dB]): configured threshold (t [dB]):
- P(in) < P(Tx) - a(Tx) - t (Tx direction) - P(in) < P(Tx) - a(Tx) - t (Tx direction)
- P(Rx) < P(out) - a(Rx) - t (Rx direction) - P(Rx) < P(out) - a(Rx) - t (Rx direction)
- a(Tx) =| a(Rx) - a(Tx) =| a(Rx)
Figure 5: Extended LMP Model Figure 5: Extended LMP Model
Pure Access Link (AL) Monitoring Use Case 5.2.1. Pure Access Link (AL) Monitoring Use Case
Figure 6 illustrates the access link monitoring use case and the
Figure 4 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
- t: user defined threshold (tolerance) - t: user defined threshold (tolerance)
- P(out): measured current optical output power at the output port - P(out): measured current optical output power at the output port
of border DWDM NE of border DWDM NE
- a(Rx): access link attenuation in Rx direction (external - a(Rx): access link attenuation in Rx direction (external
transponder point of view) transponder point of view)
- P(Rx): current optical input power of receiver Rx - P(Rx): current optical input power of receiver Rx
Description: Description:
- 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 the same. process. Typically, both values are the same.
- 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 (e.g. this draft) is in place that allows - A control plane protocol (e.g. this draft) 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 llustrated in Figure 3. This is llustrated 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 Pin and Pout as defined in G.697 by power monitoring points
depicted as yellow triangles in the figures below. depicted as yellow triangles in the figures below.
AL monitoring process: Access Llink monitoring process:
- Tx direction: the measured optical input power Pin is compared - Tx direction: the measured optical input power Pin is compared
with the expected optical input power P(Tx) - a(Tx). If the with the expected optical input power P(Tx) - a(Tx). If the
measured optical input power P(in) drops below the value measured optical input power P(in) drops below the value
(P(Tx) - a(Tx) - t) a low power alarm shall be raised indicating (P(Tx) - a(Tx) - t) a low power alarm shall be raised indicating
that the access link attenuation has exceeded a(Tx) + t. that the access link attenuation has exceeded a(Tx) + t.
- Rx direction: the measured optical input power P(Rx) is - Rx direction: the measured optical input power P(Rx) is
compared with the expected optical input power P(out) - a(Rx). compared with the expected optical input power P(out) - a(Rx).
If the measured optical input power P(Rx) drops below the value If the measured optical input power P(Rx) drops below the value
(P(out) - a(Rx) - t) a (P(out) - a(Rx) - t) a
low power alarm shall be raised indicating that the access link low power alarm shall be raised indicating that the access link
attenuation has exceeded a(Rx) + t. attenuation has exceeded a(Rx) + t.
-to avoid toggling errors, the low power alarm threshold shall be -to avoid toggling errors, the low power alarm threshold shall be
lower than the alarm clear threshold. lower than the alarm clear threshold.
Figure 6 Use case 1: Access Link power monitoring Figure 6 Use case 1: Access Link monitoring
+----------+ +--------------------------+ +----------+ +--------------------------+
| +------+ | P(Tx), P(Rx) | +-------+ | | +------+ | P(Tx), P(Rx) | +-------+ |
| | | | =================> | | | | | | | | =================> | | | |
| | LMP | | P(in), P(out) | | LMP | | | | LMP | | P(in), P(out) | | LMP | |
| | | | <================= | | | | | | | | <================= | | | |
| +------+ | | +-------+ | | +------+ | | +-------+ |
| | | | | | | |
| | | P(in) - P(Tx) - a(Tx) | | | | P(in) - P(Tx) - a(Tx) |
| | | ___ | | | | ___ |
skipping to change at page 23, line 5 skipping to change at page 22, line 5
- For AL-T monitoring: P(Tx) and a(Tx) must be known - For AL-T monitoring: P(Tx) and a(Tx) must be known
- For AL-R monitoring: P(RX) and a(Rx) must be known - For AL-R monitoring: P(RX) and a(Rx) must be known
An alarm shall be raised if P(in) or P(Rx) drops below a An alarm shall be raised if P(in) or P(Rx) drops below a
configured threshold (t [dB]): configured threshold (t [dB]):
- P(in) < P(Tx) - a(Tx) - t (Tx direction) - P(in) < P(Tx) - a(Tx) - t (Tx direction)
- P(Rx) < P(out) - a(Rx) - t (Rx direction) - P(Rx) < P(out) - a(Rx) - t (Rx direction)
- a(Tx) = a(Rx) - a(Tx) = a(Rx)
Figure 6: Extended LMP Model Figure 6: Extended LMP Model
Power Control Loop Use Case 5.2.2. Power Control Loop Use Case
This use case is based on the access link monitoring use case as This use case is based on the access link monitoring use case 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 24, line 40 skipping to change at page 23, line 40
| | RX |<---|-----\\//---------------------<|-------| \ | | | RX |<---|-----\\//---------------------<|-------| \ |
| +----+ | Access Link (AL-R) | . | | | | +----+ | Access Link (AL-R) | . | | |
| | attenuation a(Rx) | . | |<======= | | attenuation a(Rx) | . | |<=======
+----------+ | VOA(out) | | | +----------+ | VOA(out) | | |
| <--<|-------| / | | <--<|-------| / |
P(Rx) = P(out) - a(Rx) | |/ | P(Rx) = P(out) - a(Rx) | |/ |
| | | |
| ROADM | | ROADM |
+--------------------------+ +--------------------------+
Figure 7: Extended LMP Model Figure 7: Power control loop
- The Power Control Loops in Transponder and ROADM controls - The Power Control Loops in Transponder and ROADM controls
the Variable Optical Attenuators (VOA) to adjust the proper the Variable Optical Attenuators (VOA) to adjust the proper
power in base of the ROADM and Receiver caracteristics and power in base of the ROADM and Receiver caracteristics and
the Access Link attenuation the Access Link attenuation
6. Acknowledgements 6. Requirements
The author would like to thank Ulrich Drafz for the very good The authors are working on the requirement list
teamwork during the last years and the initial thoughts related to
the packet optical integration. Furthermore the author would like to
thank all people involved within Deutsche Telekom for the support and
fruitful discussions.
7. IANA Considerations 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. This memo includes no request to IANA.
8. Security Considerations 9. 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
where information is exchanged between external parties and over where information is exchanged between external parties and over
external interfaces. external interfaces.
Concerning the access control to Management interfaces, security Concerning the access control to Management interfaces, security
issues can be generally addressed by authentification techniques issues can be generally addressed by authentication techniques
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.
9. Contributors 10. 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 25, 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
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
<http://www.rfc-editor.org/info/rfc2863>. <http://www.rfc-editor.org/info/rfc2863>.
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 27, line 42 skipping to change at page 26, line 42
[ITU.G709] [ITU.G709]
International Telecommunications Union, "Interface for the International Telecommunications Union, "Interface for the
Optical Transport Network (OTN)", ITU-T Recommendation Optical Transport Network (OTN)", ITU-T Recommendation
G.709, March 2003. G.709, March 2003.
[ITU.G.872] [ITU.G.872]
International Telecommunications Union, "Architecture of International Telecommunications Union, "Architecture of
optical transport networks", ITU-T Recommendation G.872, optical transport networks", ITU-T Recommendation G.872,
November 2001. November 2001.
10.2. Informative References 11.2. Informative References
[Black-Link-MIB] [DWDM-interface-MIB]
Internet Engineering Task Force, "A SNMP MIB to manage Internet Engineering Task Force, "A SNMP MIB to manage the
black-link optical interface parameters of DWDM DWDM optical interface parameters of DWDM applications",
applications", draft-galimbe-kunze-g-698-2-snmp-mib draft- draft-galimkunze-ccamp-dwdm-if-snmp-mib draft-galimkunze-
galimbe-kunze-g-698-2-snmp-mib, July 2011. ccamp-dwdm-if-snmp-mib, July 2011.
[ITU-TG.691] [ITU-TG.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.693] [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.957] [ITU-TG.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.692]
ITU-T, "Transmission media characteristics -
Characteristics of optical components and sub-systems",
ITU-T Recommendation ITU-T G.692, 1998.
[ITU-TG.959.1] [ITU-TG.959.1]
ITU-T, "Optical transport network physical layer ITU-T, "Optical transport network physical layer
interfaces", ITU-T Recommendation ITU-T G.959.1, 2009. interfaces", ITU-T Recommendation ITU-T G.959.1, 2009.
[ITU-TG.8081] [ITU-TG.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.
Authors' Addresses Authors' Addresses
Ruediger Kunze (editor) Ruediger Kunze (editor)
Deutsche Telekom Deutsche Telekom
Dddd, xx Winterfeldtstr. 21-27
Berlin 10781 Berlin
Germany Germany
Phone: +49xxxxxxxxxx Phone: +491702275321
Email: RKunze@telekom.de Email: RKunze@telekom.de
Gert Grammel (editor) Gert Grammel (editor)
Juniper Juniper
Oskar-Schlemmer Str. 15 Oskar-Schlemmer Str. 15
80807 Muenchen 80807 Muenchen
Germany Germany
Phone: +49 1725186386 Phone: +49 1725186386
Email: ggrammel@juniper.net Email: ggrammel@juniper.net
Dieter Beller (editor) Dieter Beller (editor)
ALU Nokia
Lorenzstrasse, 10 Lorenzstrasse, 10
70435 Stuttgart 70435 Stuttgart
Germany Germany
Phone: +4971182143125 Phone: +4971182143125
Email: Dieter.Beller@alcatel-lucent.com Email: Dieter.Beller@nokia.com
Gabriele Galimberti (editor) Gabriele Galimberti (editor)
Cisco Cisco
Via S. Maria Molgora, 48 Via S. Maria Molgora, 48
20871 - Vimercate 20871 - Vimercate
Italy Italy
Phone: +390392091462 Phone: +390392091462
Email: ggalimbe@cisco.com Email: ggalimbe@cisco.com
 End of changes. 74 change blocks. 
198 lines changed or deleted 193 lines changed or added

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