draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-06.txt   draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-07.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: January 1, 2018 Juniper Expires: March 8, 2018 Juniper
D. Beller D. Beller
Nokia Nokia
G. Galimberti, Ed. G. Galimberti, Ed.
Cisco Cisco
J. Meuric J. Meuric
France Telecom Orange France Telecom Orange
June 30, 2017 September 4, 2017
A framework for Management and Control of DWDM optical interface A framework for Management and Control of DWDM optical interface
parameters parameters
draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-06 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-07
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 are a precondition for enhanced multilayer networking and interfaces are a precondition for enhanced multilayer networking and
for a further automation of network provisioning and operation. This for a further automation of network provisioning and operation. This
document describes use cases, requirements and solutions for the document describes use cases, requirements and solutions for the
control and management of optical interfaces parameters according to control and management of optical interfaces parameters according to
different types of single channel DWDM interfaces. The focus is on different types of single channel DWDM interfaces. The focus is on
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 January 1, 2018. This Internet-Draft will expire on March 8, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(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 36 skipping to change at page 2, line 36
3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Comparison of approaches for transverse compatibility . . 5 3.1. Comparison of approaches for transverse compatibility . . 5
3.1.1. Multivendor DWDM line system with transponders . . . 5 3.1.1. Multivendor DWDM line system with transponders . . . 5
3.1.2. Integrated single channel DWDM deployments on the 3.1.2. Integrated single channel DWDM deployments on the
client site . . . . . . . . . . . . . . . . . . . . . 6 client site . . . . . . . . . . . . . . . . . . . . . 6
4. Solutions for managing and controlling single channel optical 4. Solutions for managing and controlling single channel optical
interface . . . . . . . . . . . . . . . . . . . . . . . . . . 8 interface . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Separate Operation and Management Approaches . . . . . . 9 4.1. Separate Operation and Management Approaches . . . . . . 9
4.1.1. Direct connection to the management system . . . . . 9 4.1.1. Direct connection to the management system . . . . . 9
4.1.2. Indirect connection to the DWDM management system 4.1.2. Indirect connection to the DWDM management system
(first optical node) . . . . . . . . . . . . . . . . 11 (first optical node) . . . . . . . . . . . . . . . . 10
4.2. Control Plane Considerations . . . . . . . . . . . . . . 13 4.2. Control Plane Considerations . . . . . . . . . . . . . . 12
4.2.1. Considerations using GMPLS signaling . . . . . . . . 14 4.2.1. Considerations using GMPLS signaling . . . . . . . . 13
5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Link monitoring Use Cases . . . . . . . . . . . . . . . . 16 5.2. Link monitoring Use Cases . . . . . . . . . . . . . . . . 15
5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 18 5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 18
5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 21 5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 20
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
The usage of the single channel DWDM interfaces (e.g. in routers) The usage of the single channel DWDM interfaces (e.g. in routers)
connected to a DWDM Network (which include ROADMs and optical connected to a DWDM Network (which include ROADMs and optical
amplifiers) adds a further networking option for operators allowing amplifiers) adds a further networking option for operators allowing
new scenarios but require harmonised control and management plane new scenarios but require harmonised control and management plane
interaction between different network domains. interaction between different network domains.
Carriers deploy their networks today based on transport und packet Carriers deploy their networks today based on transport and packet
network infrastructures as domains to ensure high availability and a network infrastructures as domains to ensure high availability and a
high level of redundancy. Both network domains were operated and high level of redundancy. Both network domains were operated and
managed separately. This is the status quo in many carrier networks managed separately. This is the status quo in many carrier networks
today. In the case of deployments, where the optical transport today. In the case of deployments, where the optical transport
interface moves into the client device (e.g. router) an interaction interface moves into the client device (e.g. router) an interaction
between those domains becomes necessary. between those domains becomes necessary.
This framework specifies different levels of control and management This framework specifies different levels of control and management
plane interaction to support the usage of single channel optical plane interaction to support the usage of single channel optical
interfaces in carrier networks in an efficient manner. interfaces in carrier networks in an efficient manner.
The objective of this document is to provide a framework for the The objective of this document is to provide a framework for the
control and management of transceiver interfaces based on the control and management of transceiver interfaces based on the
corresponding use cases and requirements to ensure an efficient and corresponding use cases and requirements to ensure an efficient and
optimized data transport. optimized data transport.
Optical routing and wavelength assignment based on WSON is out of Although Optical routing and wavelength assignment based on WSON is
scope although can benefit of the way the optical parameters are out of scope, they can benefit from the optical parameters that are
exchanged between the Client and the DWDM Network. Also, the exchanged between the Client and the DWDM Network. Also, the
wavelength ordering process and the process how to determine the wavelength ordering process and the process how to determine the
demand for a new wavelength path through the network is out of scope. demand for a new wavelength path through the network is out of 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. that are handling the same information in different ways.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology and Definitions 2. Terminology and Definitions
The current generation of WDM netwoks are single vendor networks The current generation of WDM netwoks are single vendor networks
where the optical line system and the transponders are tightly where the optical line system and the transponders are tightly
integrated. The DWDM interfaces migration from the transponders to integrated. The DWDM interface migration from the transponders to
the colored interfaces change this scenario, by introducing a the colored interfaces change this scenario, by introducing a
standardized interface at the level of OCh between the DWDM interface standardized interface at the level of OCh between the DWDM interface
and the DWDM network. and 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
skipping to change at page 4, line 28 skipping to change at page 4, line 28
[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. rates up to 40 Gb/s.
Forward error correction (FEC): FEC is a way of improving the Forward error correction (FEC): FEC is a way of improving the
performance of high-capacity optical transmission systems. Employing performance of high-capacity optical transmission systems. Employing
FEC in optical transmission systems yields system designs that can FEC in optical transmission systems yields system designs that can
accept relatively large BER (much more than 10-12) in the optical accept relatively large BER (much more than 10-12) in the optical
transmission line (before decoding). transmission line (before decoding).
Administrative domain [G.805]: For the purposes of this Administrative domain [G.805]: the extent of resources which belong
Recommendation an administrative domain represents the extent of to a single player such as a network operator, a service provider or
resources which belong to a single player such as a network operator, an end-user. Administrative domains of different players do not
a service provider or an end-user. Administrative domains of overlap amongst themselves.
different players do not overlap amongst themselves.
Intra-domain interface (IaDI) [G.872]: A physical interface within an Intra-domain interface (IaDI) [G.872]: A physical interface within an
administrative domain. administrative domain.
Inter-domain interface (IrDI) [G.872]: A physical interface that Inter-domain interface (IrDI) [G.872]: A physical interface that
represents the boundary between two administrative domains. represents the boundary between two administrative domains.
Management Plane [G.8081]: The management plane performs management Management Plane [G.8081]: The management plane performs management
functions for the transport plane, the control plane and the system functions for the transport plane, the control plane and the system
as a whole. It also provides coordination between all the planes. as a whole. It also provides coordination between all the planes.
skipping to change at page 6, line 41 skipping to change at page 6, line 41
domain. In the case of a client DWDM interface deployment this domain. In the case of a client DWDM interface deployment this
interface moves into the client device and extends the optical and interface moves into the client device and extends the optical and
administrative domain towards the client node. ITU-T G.698.2 for administrative domain towards the client node. ITU-T G.698.2 for
example specifies the parameter set for a certain set of example specifies the parameter set for a certain set of
applications. applications.
This document elaborates only the IaDI Interface as shown in Figure 1 This document elaborates only the IaDI Interface as shown in Figure 1
as transversely compatible and multi-vendor interface within one as transversely compatible and multi-vendor interface within one
administrative domain controlled by the network operator. administrative domain controlled by the network operator.
SNMP/SMI, Yang models and LMP TLV to support the direct exchange of
information between the client and the network management and control
plane will be specified in further documents.
3.1.2. Integrated single channel DWDM deployments on the client site 3.1.2. Integrated single channel DWDM deployments on the client site
In case of a deployment as shown in Figure 2, through the use of DWDM In case of a deployment as shown in Figure 2, through the use of DWDM
interfaces, multi-vendor interconnection can also be achieved while interfaces, multi-vendor interconnection can also be achieved while
removing the need for one short reach transmitter and receiver pair removing the need for one short reach transmitter and receiver pair
per channel (eliminating the transponders). per channel (eliminating the transponders).
Figure 2 shows a set of reference points, for single-channel Figure 2 shows a set of reference points, for single-channel
connection (Ss and Rs) between transmitters (Tx) and receivers (Rx). connection (Ss and Rs) between transmitters (Tx) and receivers (Rx).
Here the DWDM network elements include an optical multiplexer (OM) Here the DWDM network elements include an optical multiplexer (OM)
skipping to change at page 8, line 5 skipping to change at page 8, line 5
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
The single administrative domain may consist of several vendor The single administrative domain may consist of several vendor
domains. Even in that case a common network management and control domains. Even in that case a common network management and control
is required to ensure a consistent operation and provisioning of the is required to ensure a consistent operation and provisioning of the
entire connection. entire connection.
The following documents[DWDM-interface-MIB], [YANG], [LMP] define SNMP/SMI, Yang models and LMP TLV to support the direct exchange of
such a protocol- FIX-THE-REFERENCE specific information using SNMP/
SMI, Yang models and LMP TLV to support the direct exchange of
information between the client and the network management and control information between the client and the network management and control
plane. plane will be specified in further documents.
4. Solutions for managing and controlling single channel optical 4. Solutions for managing and controlling single channel optical
interface 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 provisions the wavelengths. In a multi-vendor line system, that also provisions the wavelengths. In a multi-vendor line system,
such single-vendor EMS requirement is no more effective. New methods such single-vendor EMS requirement is no more effective. New methods
skipping to change at page 18, line 43 skipping to change at page 17, line 43
- 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)
Alarms and events can be shared between Client and Network
via LMP according to RFC 4204 and RFC 4209[LMP]
Figure 5: Extended LMP Model Figure 5: Extended LMP Model
5.2.1. 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 6 illustrates the access link monitoring use case and the
different physical properties involved that are defined below: different physical properties involved that are defined below:
- Ss, Rs: Single Channel reference points - Ss, Rs: Single Channel reference points
- P(Tx): current optical output power of transmitter Tx - P(Tx): current optical output power of transmitter Tx
- a(Tx): access link attenuation in Tx direction (external - a(Tx): access link attenuation in Tx direction (external
transponder point of view) transponder point of view)
- P(in): measured current optical input power at the input port - P(in): measured current optical input power at the input port
of border DWDM NE of border DWDM NE
- t: user defined threshold (tolerance) - t: user defined threshold (tolerance)
skipping to change at page 20, line 48 skipping to change at page 19, line 48
+--------------------------+ +--------------------------+
- 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)
Alarms and events can be shared between Client and Network
via LMP according to RFC 4204 and RFC 4209[LMP]
Figure 6: Extended LMP Model Figure 6: Extended LMP Model
5.2.2. 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
skipping to change at page 24, line 5 skipping to change at page 23, line 5
restoration times will be the major requirements that has been restoration times will be the major requirements that has been
addressed in this section. addressed in this section.
Data Plane interoperability as defined for example in [ITU.G698.2] is Data Plane interoperability as defined for example in [ITU.G698.2] is
a precondition to ensure plain solutions and allow the usage of a precondition to ensure plain solutions and allow the usage of
standardized interfaces between network and control/management plane. standardized interfaces between network and control/management plane.
The following requirements are focusing on the usage of DWDM The following requirements are focusing on the usage of DWDM
interfaces. interfaces.
1 To ensure a lean management and provisioning process of single 1 To ensure a lean management and provisioning process of single
channel interfaces management and control plane of the client channel interfaces management and control plane of the client
and DWDM network must be aware of the parameters of the and DWDM network MUST be aware of the parameters of the
interfaces and the optical network to properly setup the optical interfaces and the optical network to properly setup the optical
connection. connection.
2 A standard-based northbound API (to network management system) 2 A standard-based northbound API (to network management system)
based on Netconf should be supported, alternatively SNMP could based on Netconf SHOULD be supported, alternatively SNMP MAY
be supported too. be supported too.
3 A standard-based data model for single channel interfaces must be 3 A standard-based data model for single channel interfaces MUST be
supported to exchange optical parameters with control/management supported to exchange optical parameters with control/management
plane. plane.
4 Netconf should be used also for configuration of the single 4 Netconf SHOULD be used also for configuration of the single
channel interfaces including the power setting channel interfaces including the power setting
5 LMP should be extended and used in cases where optical 5 LMP SHOULD be extended and used in cases where optical
parameters need to be exchanged between peer nodes to correlate parameters need to be exchanged between peer nodes to correlate
link characteristics and adopt the working mode of the single link characteristics and adopt the working mode of the single
channel interface. channel interface.
6 LMP may be used to adjust the output power of the single 6 LMP MAY be used to adjust the output power of the single
channel DWDM interface to ensure that the interface works in channel DWDM interface to ensure that the interface works in
the right range. the right range.
7 RSVP-TE may be used to exchange some relevant parameters between 7 RSVP-TE MAY be used to exchange some relevant parameters between
the client and the optical node (e.g. the label value), without the client and the optical node (e.g. the label value), without
preventing the network to remain in charge of the optical path preventing the network to remain in charge of the optical path
computation computation
8 Power monitoring functions at both ends of the DWDM connection 8 Power monitoring functions at both ends of the DWDM connection
should be used to further automate the setup and shoutdown SHOULD be used to further automate the setup and shoutdown
process of the optical interfaces. process of the optical interfaces.
9 A standardized procedure to setup an optical connection should 9 A standardized procedure to setup an optical connection SHOULD
be defined and implemented in DWDM and client devices be defined and implemented in DWDM and client devices
(containing the single channel optical interface). (containing the single channel optical interface).
10 Pre-tested and configured backup paths should be stored in so 10 Pre-tested and configured backup paths SHOULD be stored in so
called backup profiles. In fault cases this wavelength routes called backup profiles. In fault cases this wavelength routes
should be used to recover the service. SHOULD be used to recover the service.
11 LMP may be used to monitor and observe the access link. 11 LMP MAY be used to monitor and observe the access link.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank all who supported the work with The authors would like to thank all who supported the work with
fruitful discussions and contributions. fruitful discussions and contributions.
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
skipping to change at page 27, line 8 skipping to change at page 26, line 8
ITU-T Recommendation G.698.2, November 2009. ITU-T Recommendation G.698.2, November 2009.
[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.
[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>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, Version 2 (SMIv2)", STD 58, RFC 2578,
DOI 10.17487/RFC2578, April 1999, DOI 10.17487/RFC2578, April 1999,
<http://www.rfc-editor.org/info/rfc2578>. <https://www.rfc-editor.org/info/rfc2578>.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2", Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999,
<http://www.rfc-editor.org/info/rfc2579>. <https://www.rfc-editor.org/info/rfc2579>.
[RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Conformance Statements for SMIv2", Schoenwaelder, Ed., "Conformance Statements for SMIv2",
STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999,
<http://www.rfc-editor.org/info/rfc2580>. <https://www.rfc-editor.org/info/rfc2580>.
[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>. <https://www.rfc-editor.org/info/rfc2863>.
[RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of [RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of
Managed Objects for the Optical Interface Type", RFC 3591, Managed Objects for the Optical Interface Type", RFC 3591,
DOI 10.17487/RFC3591, September 2003, DOI 10.17487/RFC3591, September 2003,
<http://www.rfc-editor.org/info/rfc3591>. <https://www.rfc-editor.org/info/rfc3591>.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
DOI 10.17487/RFC4204, October 2005,
<https://www.rfc-editor.org/info/rfc4204>.
[RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management [RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management
Protocol (LMP) for Dense Wavelength Division Multiplexing Protocol (LMP) for Dense Wavelength Division Multiplexing
(DWDM) Optical Line Systems", RFC 4209, (DWDM) Optical Line Systems", RFC 4209,
DOI 10.17487/RFC4209, October 2005, DOI 10.17487/RFC4209, October 2005,
<http://www.rfc-editor.org/info/rfc4209>. <https://www.rfc-editor.org/info/rfc4209>.
[RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for
Lambda-Switch-Capable (LSC) Label Switching Routers", Lambda-Switch-Capable (LSC) Label Switching Routers",
RFC 6205, DOI 10.17487/RFC6205, March 2011, RFC 6205, DOI 10.17487/RFC6205, March 2011,
<http://www.rfc-editor.org/info/rfc6205>. <https://www.rfc-editor.org/info/rfc6205>.
11.2. Informative References 11.2. Informative References
[DWDM-interface-MIB] [DWDM-interface-MIB]
Internet Engineering Task Force, "A SNMP MIB to manage the Internet Engineering Task Force, "A SNMP MIB to manage the
DWDM optical interface parameters of DWDM applications", DWDM optical interface parameters of DWDM applications",
draft-galimkunze-ccamp-dwdm-if-snmp-mib draft-galimkunze- draft-galimkunze-ccamp-dwdm-if-snmp-mib draft-galimkunze-
ccamp-dwdm-if-snmp-mib, July 2011. ccamp-dwdm-if-snmp-mib, July 2011.
[ITU-TG.691] [ITU-TG.691]
 End of changes. 35 change blocks. 
73 lines changed or deleted 84 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/