draft-kdkgall-ccamp-dwdm-if-mng-ctrl-fwk-00.txt   draft-kdkgall-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: April 16, 2016 Juniper Expires: April 21, 2016 Juniper
D. Beller, Ed. D. Beller, Ed.
ALU ALU
G. Galimberti, Ed. G. Galimberti, Ed.
Cisco Cisco
October 14, 2015 October 19, 2015
A framework for Management and Control of G.698.2 optical interface A framework for Management and Control of DWDM optical interface
parameters parameters
draft-kdkgall-ccamp-dwdm-if-mng-ctrl-fwk-00 draft-kdkgall-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 April 16, 2016. This Internet-Draft will expire on April 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 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 . . 7 3.1. Comparison of approaches for transverse compatibility . . 6
3.1.1. Multivendor DWDM line system with transponders . . . 7 3.1.1. Multivendor DWDM line system with transponders . . . 6
3.1.2. Black Link Deployments . . . . . . . . . . . . . . . 8 3.1.2. Black Link Deployments . . . . . . . . . . . . . . . 8
4. Solutions for managing and controlling the optical interface 4. Solutions for managing and controlling the optical interface 10
within Black Link scenarios . . . . . . . . . . . . . . . . . 10
4.1. Separate Operation and Management Approaches . . . . . . 11 4.1. Separate Operation and Management Approaches . . . . . . 11
4.1.1. Direct connection to the management system . . . . . 11 4.1.1. Direct connection to the management system . . . . . 11
4.1.2. Direct connection to the DWDM management system . . . 13 4.1.2. Direct connection to the DWDM management system . . . 13
4.2. Control Plane Considerations . . . . . . . . . . . . . . 15 4.2. Control Plane Considerations . . . . . . . . . . . . . . 15
4.2.1. Considerations using GMPLS UNI . . . . . . . . . . . 16 4.2.1. Considerations using GMPLS UNI . . . . . . . . . . . 16
5. Operational aspects using IUT-T G.698.2 specified single 5. Operational aspects using IUT-T G.698.2 specified single
channel DWDM interfaces . . . . . . . . . . . . . . . . . . . 17 channel DWDM interfaces . . . . . . . . . . . . . . . . . . . 17
5.1. Bringing into service . . . . . . . . . . . . . . . . . . 17 5.1. Bringing into service . . . . . . . . . . . . . . . . . . 17
5.2. LMP Use Cases . . . . . . . . . . . . . . . . . . . . . . 18 5.2. LMP Use Cases . . . . . . . . . . . . . . . . . . . . . . 18
6. Requirements for BL deployments . . . . . . . . . . . . . . . 25 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
6.1. Interoperability Aspects . . . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The usage of the Colored interfaces in the Client Nodes connected to The usage of the Colored interfaces in the Client Nodes connected to
a DWDM Network (which include ROADMs and optical amplifiers) adds a DWDM Network (which include ROADMs and optical amplifiers) adds
further networking option for operators opening to new scenarios and further networking option for operators opening to new scenarios and
requiring more control/management plane integration. 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
skipping to change at page 4, line 28 skipping to change at page 4, line 28
interfaces changes this scenario, by introducing a standardized interfaces changes this scenario, by introducing a standardized
interface at the level of OCh between the Client DWDM interface and interface at the level of OCh between the Client DWDM interface and
the DWDM network. the DWDM network.
Black Link: The Black Link [ITU.G698.2] allows supporting an optical Black Link: The Black Link [ITU.G698.2] allows supporting an optical
transmitter/receiver pair of a single vendor or from different transmitter/receiver pair of a single vendor or from different
vendors to provide a single optical channel interface and transport vendors to provide a single optical channel interface and transport
it over an optical network composed of amplifiers, filters, add-drop it over an optical network composed of amplifiers, filters, add-drop
multiplexers which may be from a different vendor. Therefore the multiplexers which may be from a different vendor. Therefore the
standard defines the ingress and egress parameters for the optical standard defines the ingress and egress parameters for the optical
interfaces at the reference points Ss and Rs. In that case the interfaces at the reference points Ss and Rs.
optical connection between the two G.968.2 optical interfaces is
referred to as a Black Link. G.698.2 provides an optical interface
specification ensuring the realization of transversely compatible
dense wavelength division multiplexing (DWDM) systems primarily
intended for metro applications which include optical amplifiers and
leads towards a multivendor DWDM optical transmission network.
Single Channel DWDM Interface: The single channel interfaces to DWDM Single Channel DWDM Interface: The single channel interfaces to DWDM
systems defined in G.698.2, which currently include the following systems defined in G.698.2, which currently include the following
features: channel frequency spacing: 50 GHz and wider (defined in features: channel frequency spacing: 50 GHz and wider (defined in
[ITU-T G.694.1]); bit rate of single channel: Up to 10 Gbit/s. [ITU-T G.694.1]); bit rate of single channel: Up to 10 Gbit/s.
Future revisions are expected to include application codes for bit Future revisions are expected to include application codes for bit
rates up to 40 Gb/s. Single channel DWDM interfaces to/from other rates up to 40 Gb/s.
vendor(s): G.698.2 provides transverse compatibility at the single-
channel point, using a direct wavelength-multiplexing configuration,
for single channel DWDM interfaces to/from other vendors (but not at
the multi-channel point).
Forward error correction (FEC): FEC is a way of improving the Forward error correction (FEC): FEC is a way of improving the
performance of high-capacity optical transmission systems. Employing performance of high-capacity optical transmission systems. Employing
FEC in optical transmission systems yields system designs that can FEC in optical transmission systems yields system designs that can
accept relatively large BER (much more than 10-12) in the optical accept relatively large BER (much more than 10-12) in the optical
transmission line (before decoding). transmission line (before decoding).
Administrative domain [G.805]: For the purposes of this Administrative domain [G.805]: For the purposes of this
Recommendation an administrative domain represents the extent of Recommendation an administrative domain represents the extent of
resources which belong to a single player such as a network operator, resources which belong to a single player such as a network operator,
skipping to change at page 6, line 5 skipping to change at page 5, line 43
3. Solution Space Client DWDM interface 3. Solution Space Client DWDM interface
The management of optical interfaces using the Black Link approach The management of optical interfaces using the Black Link approach
deals with aspects related to the management of single-channel deals with aspects related to the management of single-channel
optical interface parameters of physical point-to-point and ring DWDM optical interface parameters of physical point-to-point and ring DWDM
applications on single-mode optical fibres. applications on single-mode optical fibres.
The solution allows the direct connection of a wide variety of The solution allows the direct connection of a wide variety of
equipments using a DWDM link, for example: equipments using a DWDM link, for example:
a. 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
b. 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
c. 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 regarding the configuration of
optical parameters. 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 | | | | | |
skipping to change at page 10, line 17 skipping to change at page 10, line 17
To facilitate consistent end-to-end network management, the north To facilitate consistent end-to-end network management, the north
bound management interface from the EMS to the NMS should be bound management interface from the EMS to the NMS should be
consistent (frome a management information point of view) with the consistent (frome a management information point of view) with the
standard protocol-neutral (or protocol-specific) information model standard protocol-neutral (or protocol-specific) information model
used in the EMS south bound management interface to its subtending used in the EMS south bound management interface to its subtending
NEs (TX and/or RX). The [Interface-MIB] defines such a protocol- NEs (TX and/or RX). The [Interface-MIB] defines such a protocol-
specific information using SNMP/SMI, Yang models and LMP TLV to specific information using SNMP/SMI, Yang models and LMP TLV to
support the direct exchange of information between the Client and the support the direct exchange of information between the Client and the
Network control planes. Network control planes.
4. Solutions for managing and controlling the optical interface within 4. Solutions for managing and controlling the optical interface
Black Link scenarios
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 in a pure Black Link or Therefore from the operational point of view there are the following
in a mixed setup with transponders there are 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
a.Direct link between the client device and the management system a.Direct link between the client device and the management system
of the optical network (e.g. EMS, NMS) of the optical network (e.g. EMS, NMS)
b.Indirect link to the management system of the optical network b.Indirect link to the management system of the optical network
skipping to change at page 12, line 35 skipping to change at page 12, line 35
/ | |\ /| | / | |\ /| |
+---+--+ | | \ |\ / | | +------+ +---+--+ | | \ |\ / | | +------+
| CL |-/C------+-----|OM|----|/-------|OD|----+-------/C-| CL | | CL |-/C------+-----|OM|----|/-------|OD|----+-------/C-| CL |
| |-/C------+-----| |----- /|-----| |----+-------/C-| | | |-/C------+-----| |----- /|-----| |----+-------/C-| |
+------+ | | / \| \ | | +------+ +------+ | | / \| \ | | +------+
| |/ \| | | |/ \| |
| + + | | + + |
+------------------------------+ +------------------------------+
CL = Client Device CL = Client Device
/C = G.698.2 Optical Interface /C = Single Channel Optical Interface
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 3: Connecting G.698.2 optical interfaces to the Transport Figure 3: Connecting Single Channel optical interfaces to the
Management system Transport Management system
The exchange of management information between client device and the The exchange of management information between client device and the
management system assumes that some form of a direct management management system assumes that some form of a direct management
communication link exists between the client device and the DWDM communication link exists between the client device and the DWDM
management system (e.g. EMS). This may be an Ethernet Link or a DCN management system (e.g. EMS). This may be an Ethernet Link or a DCN
connection (management communication channel MCC). connection (management communication channel MCC).
It must be ensured that the optical network interface can be managed It must be ensured that the optical network interface can be managed
in a 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
skipping to change at page 14, line 20 skipping to change at page 14, line 20
| NMS | | NMS |
|_____| |_____|
/_____/ /_____/
| |
| |
| |
+---+---+ +---+---+
| EMS | | EMS |
| | | |
+-------+ +-------+
| MI | MI SNMP or Yang
| |
| |
LMP +------+-----------------------+ LMP +------+-----------------------+
+------------+---+ +| + | +------------+---+ +| + |
| | | |\ /| | | | | |\ /| |
+---+--+ | +-+ \ |\ / | | +------+ +---+--+ | +-+ \ |\ / | | +------+
| CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL | | CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL |
| |-/C------+--- -| |----- /|-----| |----+-------/C-| | | |-/C------+--- -| |----- /|-----| |----+-------/C-| |
+------+ | | / \| \ | | +------+ +------+ | | / \| \ | | +------+
| |/ \| | | |/ \| |
| + + | | + + |
+------------------------------+ +------------------------------+
CL = Client Device CL = Client Device
/C = G.698.2 optical Interface /C = Single Channel optical Interface
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
skipping to change at page 21, line 10 skipping to change at page 21, line 10
- 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 Pure Access Link (AL) Monitoring Use Case
Figure 4 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: G.698.2 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
Assumptions: 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
skipping to change at page 22, line 4 skipping to change at page 21, line 49
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
lower than the alarm clear threshold.
Figure 6 Use case 1: Access Link power monitoring Figure 6 Use case 1: Access Link power monitoring
+----------+ +--------------------------+ +----------+ +--------------------------+
| +------+ | P(Tx), P(Rx) | +-------+ | | +------+ | P(Tx), P(Rx) | +-------+ |
| | | | =================> | | | | | | | | =================> | | | |
| | LMP | | P(in), P(out) | | LMP | | | | LMP | | P(in), P(out) | | LMP | |
| | | | <================= | | | | | | | | <================= | | | |
| +------+ | | +-------+ | | +------+ | | +-------+ |
| | | | | | | |
skipping to change at page 24, line 40 skipping to change at page 24, 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 |
+--------------------------+ +--------------------------+
- The Power Control Loops in Transponder and ROADM regulate Figure 7: Extended LMP Model
- 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
Figure 7: Extended LMP Model 6. Acknowledgements
6. Requirements for BL deployments
This section raises requirements from the carrier perspective and
will be removed in a separate requirements draft if necessary.
6.1. Interoperability Aspects
For carrier network deployments, interoperability is a key
requirement. Today it is state-of-the-art to interconnect e.g.
client devices from different vendors via a WDM transport system
using short-reach, grey interfaces. Applying the Black Link (BL)
concept, client devices (e.g. routers) are now directly connected via
transport interfaces which must be interoperable to each other.
A progressive approach addressing interoperability is shown in
Figure 8.According to the concept of ITU-T G.698.2 the black link,
the single channel (coloured) Tx and the Rx can be provided different
vendors. The single-channel reference points Ss and Rs indicate the
demarcation between the Tx/Rx and the black link, and the set of
optical parameters refers to these reference points according to
G.698.2. However, G.698.2 does not give any insight into the client
equipment (CL), e.g. routers or switches, containing the optical
transmitters and receivers. This is a valid topic which is subject
of other standards and multi-source agreement (MSAs) describing
electrical interfaces, mechanical properties and environmental
conditions. Such topics are out of the scope of this document.
<========= Black Link =========>
+---------------------------+
| Black Link |
+-----------+ | + + | +-----------+
|CL #1 | -+---|\ /|---+- | CL #2 |
| +------+-+ | | \ +-------+ / | | +-+------+ |
| -+-| Tx | | | | | | | | | | Rx |-+- |
| -+-| +--+-+---|OM|-- OADM |--|OD|---+-+--+ |-+- |
| -+-| | Ss | | | | | | | | RS | |-+- |
| +------+-+ | | / +-------+ \ | | +-+------+ |
| | -+---|/ \|---+- | |
| | | + + | | |
+-----------+ | | +-----------+
+---------------------------+
CL = Client Device
OM = Optical Mux
OD = Optical Demux
Figure 8: Interoperability aspects
7. Acknowledgements
The author would like to thank Ulrich Drafz for the very good The author would like to thank Ulrich Drafz for the very good
teamwork during the last years and the initial thoughts related to teamwork during the last years and the initial thoughts related to
the packet optical integration. Furthermore the author would like to the packet optical integration. Furthermore the author would like to
thank all people involved within Deutsche Telekom for the support and thank all people involved within Deutsche Telekom for the support and
fruitful discussions. fruitful discussions.
8. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 8. Security Considerations
The architecture and solution space in scope of this framework The architecture and solution space in scope of this framework
imposes no additional requirements to the security models already imposes no additional requirements to the security models already
defined in RFC5920 for packet/optical networks using GMPLS, covering defined in RFC5920 for packet/optical networks using GMPLS, covering
also Control Plane and Management interfaces. Respective security also Control Plane and Management interfaces. Respective security
mechanisms of the components and protocols, e.g. LMP security mechanisms of the components and protocols, e.g. LMP security
models, can be applied unchanged. models, can be applied unchanged.
As this framework is focusing on the single operator use case, the As this framework is focusing on the single operator use case, the
security concerns can be relaxed to a subset compared to a setup security concerns can be relaxed to a subset compared to a setup
skipping to change at page 27, line 35 skipping to change at page 25, line 43
providing origin verification, integrity and confidentiality. providing origin verification, integrity and confidentiality.
Additionally, access to Management interfaces can be physically or Additionally, access to Management interfaces can be physically or
logically isolated, by configuring them to be only accessible out-of- logically isolated, by configuring them to be only accessible out-of-
band, through a system that is physically or logically separated from band, through a system that is physically or logically separated from
the rest of the network infrastructure. In case where management the rest of the network infrastructure. In case where management
interfaces are accessible in-band at the client device or within the interfaces are accessible in-band at the client device or within the
optical transport netork domain, filtering or firewalling techniques optical transport netork domain, filtering or firewalling techniques
can be used to restrict unauthorized in-band traffic. Authentication can be used to restrict unauthorized in-band traffic. Authentication
techniques may be additionally used in all cases. techniques may be additionally used in all cases.
10. Contributors 9. 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 28, line 28 skipping to change at page 26, line 28
Darmstadt Darmstadt
Germany Germany
email j.roese@telekom.de email j.roese@telekom.de
Frank Luennemann Frank Luennemann
Deutsche Telekom Deutsche Telekom
Muenster Muenster
Germany Germany
email Frank.Luennemann@telekom.de email Frank.Luennemann@telekom.de
11. References 10. References
11.1. Normative References 10.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 29, line 42 skipping to change at page 27, 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.
11.2. Informative References 10.2. Informative References
[Black-Link-MIB] [Black-Link-MIB]
Internet Engineering Task Force, "A SNMP MIB to manage Internet Engineering Task Force, "A SNMP MIB to manage
black-link optical interface parameters of DWDM black-link optical interface parameters of DWDM
applications", draft-galimbe-kunze-g-698-2-snmp-mib draft- applications", draft-galimbe-kunze-g-698-2-snmp-mib draft-
galimbe-kunze-g-698-2-snmp-mib, July 2011. galimbe-kunze-g-698-2-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",
 End of changes. 30 change blocks. 
104 lines changed or deleted 44 lines changed or added

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