Internet Engineering Task Force R.Kunze, Ed.
Internet-Draft Deutsche Telekom AG
Intended status: Informational G.Grammel, Ed.
Expires: May 3, 2012 H.Schmidtke, Ed.
Juniper Networks
GMG. G.Galimberti, Ed.
Cisco
October 31, 2011
A framework for Management and Control of optical interfaces supporting
G.698.2
draft-kunze-g-698-2-management-control-framework-01
Abstract
This document provides a framework that describes a solution space
for the control and management of optical interfaces according to the
Black Link approach as specified by ITU-T [ITU.G698.2] and further
revisions. In particular, it examines topological elements and
related network management measures.
Optical Routing and Wavelength assignment based on WSON is out of
scope. This document concentrates on the management of optical
interfaces. The application of a dynamic control plane, e.g. for
auto-discovery or for the distribtion of interface parameters, is
complementary. Anyway, this work is not in conflict with WSON but
leverages and supports related work already done for management plane
and control plane.
The framework document will not address the client mapping into
G.709. This document only addresses the lower layers. Furthermore,
support for Fast Fault Detection, to e.g. trigger Protection
Switching is provided by the WDM interface capability of the client
interface (e.g. ITU-T G.709) is out of scope for this work.
Additionally the wavelength ordering process and the process how to
determine the demand for a new wavelength from A to Z is out of
scope.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
R.Kunze, et al. Expires May 3, 2012 [Page 1]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
R.Kunze, et al. Expires May 3, 2012 [Page 2]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
3. Solution Space for optical interfaces using a DWDM Black
Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Description of Client Network Layer - WDM connection . . . 7
3.1.1. Traditional WDM deployments . . . . . . . . . . . . . 7
3.1.2. Black Link Deployments . . . . . . . . . . . . . . . . 8
4. Operational aspects using G.698 specified coloured
interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Bringing into service . . . . . . . . . . . . . . . . . . 10
4.2. Configuration Management . . . . . . . . . . . . . . . . . 11
4.3. In service (performance management) . . . . . . . . . . . 11
4.4. Fault Clearance . . . . . . . . . . . . . . . . . . . . . 11
5. Solutions managing and control the optical interface
within BL sceanrios . . . . . . . . . . . . . . . . . . . . . 11
5.1. BL Separate Operation and Management Approaches . . . . . 12
5.1.1. Direct connection to the management system . . . . . . 13
5.1.2. Indirect connection to the WDM management system . . . 15
5.2. Control Plane Considerations . . . . . . . . . . . . . . . 16
5.2.1. Stub Control Plane on the packet network . . . . . . . 17
5.2.2. Deployment of a common control plane . . . . . . . . . 17
5.2.3. Black Link deployment with an separate control
plane . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Requirements for BL and FW deployments . . . . . . . . . . . . 18
6.1. Interoperability Aspects . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21
R.Kunze, et al. Expires May 3, 2012 [Page 3]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
1. Introduction
The usage of the Black Link approach in carrier long haul and
aggregation networks adds a further option for operators to
facilitate their networks. The integration of optical coloured
interfaces into routers and other types of clients could lead to a
lot of benefits regarding an efficient and optimized data transport
for higher layer services.
Carriers deploy their networks today as a combination of transport
and packet infrastructure. This ensures high available and flexible
data transport. Both network technologies are managed usually by
different operational units using different management concepts.
This is the status quo in many carrier networks today. In the case
of a black link deployment, where the coloured interface moves into
the client (e.g. router), it is necessary to establish a management
connection between the client providing the coloured interface and
the corresponding EMS (Element Management System) of the transport
network to ensure that the coloured interface parameters can be
managed in the same way as traditional deployments allow this.
The objective of this document is to provide a framework that
describes the solution space for the control and management of WDM
Black Links as specified by ITU-T [ITU.G698.2] and further revisions.
In particular, it examines topological elements and related network
management measures.
Optical Routing and Wavelength assignment based on WSON is out of
scope. This document concentrates on the management of optical
interfaces. The application of a dynamic control plane, e.g. for
auto-discovery or distribute interface parameters, is complementary.
Anyway, this work is not in conflict with WSON but leverages and
supports related work already done for management plane and control
plane.
Furthermore, support for Fast Fault Detection, to e.g. trigger
Protection Switching is provided by the WDM interface capability of
the client interface (e.g. ITU-T G.709) is out of scope for this
work. Additionally the wavelength ordering process and the process
how to determine the demand for a new wavelength from A to Z is out
of scope.
Note that Control and Management Plane are two separate entities that
are handling the same information in different ways. This document
covers management as well as control plane considerations in
different management cases of colored interfaces.
R.Kunze, et al. Expires May 3, 2012 [Page 4]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology and Definitions
Black Link: The Black Link [ITU.G698.2] allows supporting an optical
transmitter/receiver pair of one or different vendors to inject a
DWDM channel and run it over an optical network composed of
amplifiers, filters, add-drop multiplexers from a different vendor.
Therefore the standard defines the ingress and egress parameters for
the optical interfaces at the reference points Ss and Rs. In that
case the DWDM network between the two colored interfaces is also
referred to as 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.
Coloured Interface: The term coloured interface defines the single
channel optical interface that is used to bridge long distances and
is directly connected with a DWDM system. Coloured interfaces
operate on a fix wavelength or within a wavelength band (tunability).
Coloured interface is a generic term and relates to WDM systems in
general, not just black link systems.
Friendly Wavelength: A wavelength that is managed by the DWDM System.
Alien Wavelength: A wavelength that is not managed and known by the
WDM system.
Forward error correction (FEC): FEC is an important way of improving
the performance of high-capacity long haul optical transmission
systems. Employing FEC in optical transmission systems yields system
designs that can accept relatively large BER (much more than 10-12)
in the optical transmission line (before decoding).
Administrative domain [G.805]: For the purposes of this
Recommendation an administrative domain represents the extent of
resources which belong to a single player such as a network operator,
a service provider or an end-user. Administrative domains of
different players do not overlap amongst themselves.
Intra-domain interface (IaDI) [G.870]: A physical interface within an
administrative domain.
R.Kunze, et al. Expires May 3, 2012 [Page 5]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
Inter-domain interface (IrDI) [G.870]: A physical interface that
represents the boundary between two administrative domains.
Vendor domain: tbd.
Management Plane: Management Plane: The management plane supports
FCAPS (Fault, Configuration, Accounting, Performance and Security
Management) capabilities for carrier networks.
Control Plane: The control plane supports signalling, path
computation, routing, path provisioning and recovery.
Client Network Layer: The client network layer is the layer above (on
top) the WDM layer, from the perspective of the WDM layer.
Transponder: A Transponder is a network element that performs O/E/O
(Optical /Electrical/Optical) conversion. In this document it is
referred only transponders with 3R (rather than 2R or 1R
regeneration) as defined in [ITU.G.872]
3. Solution Space for optical interfaces using a DWDM Black Link
Basically the management of optical interfaces using a Black Link
deals with aspects needed for setup, tear down and maintenance of
wavelengths and all related optical parameters, which are demanded by
a client network layer (the layer above WDM) or by a different
administrative domain. The following types of WDM networks are
considered for a management of optical interfaces using a black link:
a. Passive WDM
b. Legacy point to point WDM systems
c. Legacy WDM systems with OADMs
d. Transparent optical networks supporting specific IPoDWDM
functions, interfaces or protocols
Table 1 provides a list of tasks, which are related to BL management,
It is indicated which domain (optical or client) is responsible for a
task. The relevance of a task for each type of WDM network is also
indicated.
R.Kunze, et al. Expires May 3, 2012 [Page 6]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
+---------------------------------------+---------+----+----+---+---+
| Task | Domain | a | b | c | d |
+---------------------------------------+---------+----+----+---+---+
| determination of centre frequency | client | R | R | R | R |
| configuration of centre frequency at | optical | NR | NR | R | R |
| colored IF | | | | | |
| path computation of wavelength | optical | NR | NR | R | R |
| routing of wavelength | optical | NR | NR | R | R |
| wavelength setup across optical | client | ? | ? | R | R |
| network | | | | | |
| detection of wavelength fault | optical | R | R | R | R |
| fault isolation, identification of | optical | NR | R | R | R |
| root failure | | | | | |
| repair actions within optical network | optical | R | R | R | R |
| protection switching of wavelength | optical | NR | NR | R | R |
| restoration of wavelength | optical | NR | NR | R | R |
+---------------------------------------+---------+----+----+---+---+
Note: R = relevant, NR = not relevant
Table 1: List of tasks related to BL management
Furthermore the following deployment cases will be considered:
a. Exclusive Black Link deployment
b. Black Link deplyoment in combination with grey client network
interfaces
Case b) is motivated by the usage of legacy equipment using the
traditional connection as described in Figure 1 combined with the BL
approach.
3.1. Description of Client Network Layer - WDM connection
3.1.1. Traditional WDM deployments
The ordinary connection of a client layer network towards a WDM
system is based today on client interfaces (grey) bridging short or
intermediate distances between client and WDM system. The Optical
Signal incoming into the WDM system must be converted (OEO
conversion) to corresponding WDM wavelength grid and the power level
that is applicable for the WDM transmission path. This conversion is
done by a component termed as transponder (see Figure 1).
After that OEO conversion the signal complies with the parameters
that are specified for a certain WDM link.
R.Kunze, et al. Expires May 3, 2012 [Page 7]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
Figure 1 shows the traditional Client - WDM interconnection using
transponders for wavelength conversion. IrDI and IaDI as defined in
Section 2 specifying the different demarcation areas related to
external and internal connections
IrDI IaDI
| |
. .
| +----------------------------|---+
. | + WDM Domain + . |
| | |\ /| | |
+------+ . | | \ |\ / | . | +------+
| CL |-->--+---+--T/-|OM|----|/-------|OD|--+-\T+------->--| CL |
| |--<--+---+--T/-| |----- /|-----| |--.-\T+-------<--| |
+------+ | | | / \| \ | | | +------+
. | |/ \| . |
| | + + | |
. +----------------------------.---+
| |
CL = Client
T/ = Transponder
OM = Optical Mux
OD = Optical Demux
Figure 1: Inter and Intra-Domain Interface Identification
This document refers only on the IaDI Interface as specified in ITU-T
G.698.2 as transversely compatible and multi-vendor interface within
one 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).
The management and control of WDM and client layer is done by
different control and management solutions. Different operational
units are responsible for client and WDM layer.
3.1.2. Black Link Deployments
In case of a black link deployment Figure 2 the DWDM transceiver is
located directly at the client and the grey interfaces will be saved.
In that case a solution must be found to manage that coloured
interface in the same way as in the traditional case. This
requirement must be fulfilled especially in the cases where legacy
equipment and Black Link Wavelength interfaces will be used in
R.Kunze, et al. Expires May 3, 2012 [Page 8]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
parallel or together and the operational situation is unchanged.
Figure 2 shows a set of reference points, for the linear "black-link"
approach, for single-channel connection (Ss and Rs) between
transmitters (Tx) and receivers (Rx). Here the WDM network elements
include an OM and an OD (which are used as a pair with the opposing
element), one or more optical amplifiers and may also include one or
more OADMs.
|==================== Black Link =======================|
+-------------------------------------------------+
Ss | DWDM Network Elements | Rs
+---+ | | | \ / | | | +---+
Tx L1----|->| \ +------+ +------+ / |--|--->Rx L1
+---+ | | | | | +------+ | | | | | +---+
+---+ | | | | | | | | | | | | +---+
Tx L2----|->| OM |-|>|------|->| OADM |--|------|->| OD |--|--->Rx L2
+---+ | | | | | | | | | | | | +---+
+---+ | | | | | +------+ | | | | | +---+
Tx L3----|->| / | DWDM | | ^ | DWDM | \ |--|--->Rx L3
+---+ | | / | Link +----|--|----+ Link | \ | | +---+
+-----------+ | | +----------+
+--+ +--+
| |
v |
+---+ +---+
RxLx TxLx
+---+ +---+
Ss = reference point at the DWDM network element tributary output
Rs = reference point at the DWDM network element tributary input
Lx = Lambda x
OM = Optical Mux
OD = Optical Demux
OADM = Optical Add Drop Mux
from Fig. 5.1/G.698.2
Figure 2: Linear Black Link
Independent from the WDM networks that are considered the usage of
colored interfaces must perform as well in mixed setups with both
legacy and colored interface equipment using the BL.
R.Kunze, et al. Expires May 3, 2012 [Page 9]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
4. Operational aspects using G.698 specified coloured interfaces
A Comparison of the black link with the traditional operation
scenarios provides an insight of similarities and distinctions in
operation and management. The following four use cases provide an
overview about operation and maintenance processes.
4.1. Bringing into service
It is necessary to differentiate between two operational issues
setting up a wavelength path within an optical network. The first is
the preparation of the link if no optical circuit on the system
exits. This configuration is then the first task of the transport
management. Therefore it is necessary:
a. to define/calculate the path of the connection
b. to configure all involved network elements and
c. to verify software versions and alarms.
This task could be done manually supported by the EMS/NMS of the
optical transport network or automated.
The second step is to setup the circuit. From the operation point of
view it is the same task in a black link scenario and in a
traditional environment. The circuit must be setup logically at
first. In the traditional case, where no control plane is in use
this is a task of the operational staff as well. It must be known
what type of framing is used to setup the link and which nodes are
involved. Furthermore it must be decided and specified if an
alternative path has to be configured for protection. An additional
wavelength path could be specified for protection purposes.
From this point now the operational stuff needs access to the client
to configure the optical interface. The optical interface must be
patched to the right ingress port of the optical transport node (e.g.
ROADM or OADM/OM) and must be known in the inventory of the transport
management system.
The transport staff must know for example the router name, the
interface type, name and address to ensure to configure the right
interface. This is needed in the transponder case as well. After
configuring all parameters the connection will be monitored for a
certain time period. If monitoring is successful then the connection
will be announced in the IGP and is in use then.
The only difference in case of a black link scenario is that the
R.Kunze, et al. Expires May 3, 2012 [Page 10]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
coloured interface that moved into the client is belongs to the
optical path (creation and termination of the optical wavelength
path) and must be configured ideally by the optical transport
operation stuff too.
The two last steps could be automated in a case of black link setup.
After patching the router towards the first transport node a
management connection will be established over a different control
channel using an extended UNI to exchange configuration information
(see chapter xyz)
Due to the fully tuneable interfaces used in the Black Link scenario
it is possible to define a second wavelength for restoration/
resilience that can be tested and stored in backup profile. In fault
cases this wavelength can be used to recover the service.
4.2. Configuration Management
tbd.
4.3. In service (performance management)
tbd.
4.4. Fault Clearance
tbd.
5. Solutions managing and control the optical interface within BL
sceanrios
Operation and management of WDM systems is traditionally seen as a
homogenous group of tasks that could be carried out best when a
single management system or an umbrella management system is used.
Each WDM vendor provides a management system that also administrates
the wavelengths.
This old operational approach was based on a high amount/rate of
connection oriented traffic in carrier networks. This behaviour has
been changed completely. Today IP is the dominating traffic in the
network and from the operating perspective it is more beneficial to
use a common management and operation approach. Due to a long
history of operational separation it must be possible to manage and
operate the optical interface using a Black Link with the traditional
approach too.
Therefore from the operational point of view in a pure Black Link or
in a mixed setup with legacy equipment (transponders) there are two
R.Kunze, et al. Expires May 3, 2012 [Page 11]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
approaches to manage and operate optical interfaces.
1. Separate operation and management of client and Transport network
a. Direct link to the management from the client system to the
optical domain (e.g. EMS, OSS)
b. Indirect link to the management system; using a protocol
between the peer node and the directly connected WDM system node
to exchange management information with the optical domain
2. Common operation and management of client and Transport network
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
Management (Fault, Configuration, Accounting, Performance and
Security) capabilities are supported. This means from the management
staff point of view nothing changes. The transceiver/receiver
optical interface will be part of the optical management domain and
will be managed from the transport management staff.
The second option should be favoured if the underlying WDM transport
network is mainly used to interconnect IP nodes and the service
creation and restoration will be done on higher layers (e.g. IP/
MPLS). Then it is more beneficial have a higher level of integration
and a common management will be more efficient.
5.1. BL Separate Operation and Management Approaches
R.Kunze, et al. Expires May 3, 2012 [Page 12]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
5.1.1. Direct connection to the management system
As depicted in Figure 3 one possibility to manage the optical
interface within the client is a direct connection to the management
system of the optical domain. This ensures manageability as usual.
+-----+
| OSS |
|_____|
/_____/
|
|
|
+---+---+
+----->+ EMS |
/ | |
/ +-------+
/ | MI
SNMP / | DCN Network
--------------------+-------------------------------
/ +------+-----------------------+
/ | +| WDM Domain + |
/ | |\ /| |
+---+--+ | | \ |\ / | | +------+
| CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL |
| |-/C------+--- -| |----- /|-----| |----+-------/C-| |
+------+ | | / \| \ | | +------+
| |/ \| |
| + + |
+------------------------------+
CL = Client
/C = Coloured Interface
OM = Optical Mux
OD = Optical Demux
EMS = Element Management System
MI= Management Interface
Figure 3: Connecting BL on Transport Management
The exchange of management information between client and management
system assumes that some form of a direct link exists between the
client node and the WDM management system (e.g. EMS). This may be
an Ethernet Link or a DCN connection.
R.Kunze, et al. Expires May 3, 2012 [Page 13]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
It must be ensured that the optical interface can be managed in a
standardized way to enable interoperable solutions between different
optical interface vendors and vendors of the optical network
management software. RFC 3591 [RFC3591] defines manage objects for
the optical interface type but does not cover the scenarios described
by this framework document. 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 data between client and management
system of the WDM domain.
Note that a software update of the interface components of the client
does not lead obligatory to an update of the software of the EMS and
vice versa.
R.Kunze, et al. Expires May 3, 2012 [Page 14]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
5.1.2. Indirect connection to the WDM management system
The alternative as shown in Figure 4 can be used in cases where a
more automated relationship between transport node and router is
aspired. In that case a combination of rudimentary control plane
features and manual management will be used. It is a first step into
a more control plane oriented operation model.
+-----+
| OSS |
|_____|
/_____/
|
|
|
+---+---+
| EMS |
| |
+-------+
| MI
|
|
LMP(XML) +------+-----------------------+
+------------+---+ +| + |
| | | |\ /| |
+---+--+ | +-+ \ |\ / | | +------+
| CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL |
| |-/C------+--- -| |----- /|-----| |----+-------/C-| |
+------+ | | / \| \ | | +------+
| |/ \| |
| + + |
+------------------------------+
CL = Client
/C = Coloured Interface
OM = Optical Mux
OD = Optical Demux
EMS= Element Management System
MI= Management Interface
Figure 4: Direct connection between peer node and first optical
network node
For information exchange between client and the direct connected node
of the optical transport network LMP as specified in RFC 4209
R.Kunze, et al. Expires May 3, 2012 [Page 15]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
[RFC4209] can (should) be used. This extension of LMP may be used
between a peer node and an adjacent optical network node as depicted
in Figure 4.
Recently LMP based on RFC 4209 does not support the transmission of
configuration data (information). This functionality has to be added
to the existing extensions of the protocol. The use LMP-WDM assumes
that some form of a control channel exists between the client node
and the WDM equipment. This may be a dedicated lambda, an Ethernet
Link, or a DCN. It is proposed to use an out of band signalling over
a separate link or DCN to ensure a high availability.
5.2. Control Plane Considerations
Basically it is not mandatory necessary to run a control plane in
Black Link scenarios at least not in simple black link case where
clients will be connected point to point using a simple WDM
infrastructure (multiplexer and amplifier). As a first step it is
possible to configure the entire link using the standard management
system and a direct connection of the router or client to the EMS of
the transport network. Configuration information will be exchanged
via a network management protocol. This could be SNMP(see sections
Section 5.1.1).
Looking at the control plane the following two scenarios may be
considered:
a. A control plane is only used on the packet layer, transport in
further managed using a traditional management system EMS/NMS.Its
called Stub-Control plane.
b. A common control plane for transport and client network; this
implies a single operation unit responsible for both client and
transport network management.
c. A separate control plane for client and optical network without
any interaction
As mentioned in chapter Section 5.1.2 some control plane features
like LMP in an enhanced version could be used.
In such simple scenario it is imaginable to use only LMP to exchange
information between the nodes of the optical domain. LMP must be run
between the both end-points of the link and between the edge node and
the first optical network node.
R.Kunze, et al. Expires May 3, 2012 [Page 16]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
5.2.1. Stub Control Plane on the packet network
Stub control plane means here that a control plane is used in the
packet network only and the optical transport uses a management
system for configuration. The type of control plane that is used in
that case doesnt matter. It could be an IP or IP/MPLS control plane
for example.
This scenario is used when no fully control plane is supported by the
optical transport network. In this case an extended version of LMP
for example could be used to monitor the link between transport
management system and the client hosting the optical interfaces.
This makes it possible to exchange configuration parameters towards
the node hosting the coloured interface and on the other side send
important FCAP information towards the transport management system.
An additional control plane is not needed initially. A communication
channel (out of band) must be used to automate the configuration and
setup process.
This model could be seen as an evolutionary step into the direction
of a GMPLS Control plane and only the edge node and the first core
node need to run this protocol. The wavelength that should be used
by the coloured interface can be assigned manually.If the connection
comes up the IGP announces it and the metric will be adapted that the
link is in operation.
This horizontal communication is needed to virtually integrate the
optical part of the interface towards the optical transport system
keeping the status quo as today.In case of more static networks using
the current paradigm of network design this model has a lot benefits.
It keeps the network simple and adds some beneficial features to the
network to automate the operational processes and make operation
easier.
5.2.2. Deployment of a common control plane
The deployment of coloured interfaces is leading to some changes
related to the control plane models and has some impact on the
existing interfaces especially in the 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 protocol instance that runs
among the core nodes. RFC 4208 [RFC4208] defines the GMPLS UNI that
will be used between edge and core node. In case of a black link
deployment this UNI moves into the client that hosts the coloured
interface. This means that the overlay starts at the same node that
is as well part of the transport infrastructure starting and
terminating the wavelength channel.
R.Kunze, et al. Expires May 3, 2012 [Page 17]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
Lets differentiate between topology/signalling information that must
or could be exchanged and configuration parameters needed to setup a
wavelength path like wavelength, modulation scheme, FEC and other
important parameters. RSVP-TE could be used for the signalling and
the reservation of the wavelength path. But there is more
information needed in case of a wavelength path setup. Now there are
two possibilities to proceed:
a. Using RSVP-TE only for the signalling and LMP as described above
to exchange information to configure the optical interface within
the edge node or
b. RSVP-TE will be used to transport additional information
c. Leaking IGP information instead of exchanging this information
needed from the optical network to the edge node (overlay will be
transformed to a border-peer model)
In any case the classic overlay moves into the edge node or client
and in any case of using the overlay model additional parameters need
to be exchanged between edge node and optical core node. The
following issues must be solved:
Communication between peering edge nodes using an out of band control
channel. The two node have to exchange their optical capabilities
(LMP:do we need to extend LMP in that case), FEC Modulation scheme,
etc must be the same. It would be helpful to define some common
profiles that will be supported. Only if the profiles match with
both interface capabilities it is possible start signalling.
Due to the bidirectional wavelength path that must be setup it is
obligatory that the upstream edge node inserts a wavelength value
into the path message for the wavelength path towards the upstream
node itself. But in the case of an overlay model the client has not
the information which wavelength must should be selected and this
information must be exchanged between edge and the core node.
Other points
5.2.3. Black Link deployment with an separate control plane
tbd.
6. Requirements for BL and FW deployments
This section raises requirements from the carrier perspective and
will be removed in a separate requirements draft if necessary.
R.Kunze, et al. Expires May 3, 2012 [Page 18]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
6.1. Interoperability Aspects
For carrier network deployments, interoperability is a key
requirement. Today it is state-of-the-art to interconnect e.g.
clients from different vendors and a WDM transport system using
short-reach, grey interfaces. Applying the Black Link (BL) concept,
clients (e.g. routers) now become directly connected via transport
interfaces which must be interoperable to each other.
<========= Black Link =========>
+---------------------------+
| Black Link (vendor A) |
+-----------+ | + + | +-----------+
|CL #1 | -+---|\ /|---+- | CL #2 |
| +------+-+ | | \ +-------+ / | | +-+------+ |
| --| Tx | | | | | | | | | | Rx |-- |
| --|(vendor +--+-+---|OM|-- OADM |--|OD|---+-+--+(vendor |-- |
| --| X) | Ss | | | | | | | | RS | Y) |-- |
| +------+-+ | | / +-------+ \ | | +-+------+ |
| | -+---|/ \|---+- | |
|(vendor B1)| | + + | |(vendor B2)|
+-----------+ | | +-----------+
+---------------------------+
CL = Client
/C = Coloured Interface
OM = Optical Mux
OD = Optical Demux
EMS= Element Management System
MI= Management Interface
Figure 5: Interoperability aspects
In practice, a network operator may not use five different vendors
when implementing black link systems. A simplified use case could be
to choose the same vendor B for the client equipment on both sides
(i.e. vendor B1 = vendor B2 = vendor B) and to choose the same vendor
X for the Tx and Rx (i.e. vendor X = vendor Y) thus enabling to use
universal pluggable modules for the optical transmitters and
receivers.
An even more simplified use case could be to choose the same vendor B
for all client equipment and Tx/Rx (i.e. B = B1 = X = B2 = Y) thus
having only two vendors for the whole set-up, namely vendor A and
R.Kunze, et al. Expires May 3, 2012 [Page 19]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
vendor B, but to give up the possibility to use universal pluggable
modules.
Other vendor combinations could also be realized (e.g. vendor X =
vendor Y = vendor A).
7. Acknowledgements
The author would like to thank Ulrich Drafz for the very good
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.
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
This document has no requirement for a change to the security models
within GMPLS, associated protocols and management interfaces. As
well as the LMP security models could be operated unchanged.
10. Contributors
Arnold Mattheus
Deutsche Telekom
Darmstadt
Germany
email arnold.Mattheus@telekom.de
Manuel Paul
Deutsche Telekom
Berlin
Germany
email Manuel.Paul@telekom.de
Josef Roese
Deutsche Telekom
Darmstadt
Germany
email j.roese@telekom.de
Frank Luennemann
Deutsche Telekom
Muenster
Germany
R.Kunze, et al. Expires May 3, 2012 [Page 20]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
email Frank.Luennemann@telekom.de
11. References
11.1. Normative References
[ITU.G.872] International Telecommunications Union,
"Architecture of optical transport networks", ITU-
T Recommendation G.872, November 2001.
[ITU.G698.2] International Telecommunications Union, "Amplified
multichannel dense wavelength division multiplexing
applications with single channel optical
interfaces", ITU-T Recommendation G.698.2,
November 2009.
[ITU.G709] International Telecommunications Union, "Interface
for the Optical Transport Network (OTN)", ITU-
T Recommendation G.709, March 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions
of Managed Objects for the Optical Interface Type",
RFC 3591, September 2003.
[RFC4204] Lang, J., "Link Management Protocol (LMP)",
RFC 4204, October 2005.
[RFC4209] Fredette, A. and J. Lang, "Link Management Protocol
(LMP) for Dense Wavelength Division Multiplexing
(DWDM) Optical Line Systems", RFC 4209,
October 2005.
11.2. Informative References
[Black-Link-MIB] Internet Engineering Task Force, "A SNMP MIB to
manage the optical colored interfaces of a DWDM
network", draft-galimbe-kunze-g-698-2-snmp-
mib draft-galimbe-kunze-g-698-2-snmp-mib,
July 2011.
R.Kunze, et al. Expires May 3, 2012 [Page 21]
Internet-Draft draft-kunze-g698-mgnt-ctrl-framework-01 October 2011
Authors' Addresses
Ruediger Kunze (editor)
Deutsche Telekom AG
Berlin, 10589
DE
Phone: +49 30 3497 3152
EMail: ruediger.kunze@telekom.de
Gert Grammel (editor)
Juniper Networks
ddddd
dddd, 1234
US
Phone: +1 45552
EMail: ggrammel@juniper.net
Hans-Juergen Schmidtke (editor)
Juniper Networks
dddd, 1234
US
Phone: +1 45552
EMail: hschmidtke@juniper.net
Gabriele Galimberti (editor)
Cisco
Via Philips,12
20052 - Monza
Italy
Phone: +390392091462
EMail: ggalimbe@cisco.com
R.Kunze, et al. Expires May 3, 2012 [Page 22]