draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-10.txt   draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11.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: December 8, 2018 Juniper Expires: December 13, 2018 Juniper
D. Beller D. Beller
Nokia Nokia
G. Galimberti, Ed. G. Galimberti, Ed.
Cisco Cisco
J. Meuric J. Meuric
Orange Orange
June 6, 2018 June 11, 2018
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-10 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11
Abstract Abstract
The control and management of DWDM interfaces are a precondition for The control and management of DWDM interfaces are a precondition for
enhanced multilayer networking. They are needed to ensure an enhanced multilayer networking. They are needed to ensure an
efficient data transport, to meet the requirements requested by efficient data transport, to meet the requirements requested by
today's IP-services and to provide a further automation of network today's IP-services and to provide a further automation of network
provisioning and operations. This document describes use cases, provisioning and operations. This document describes use cases,
requirements and solutions for the control and management of optical requirements and solutions for the control and management of optical
interface parameters according to different types of single channel interface parameters according to different types of single channel
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 8, 2018. This Internet-Draft will expire on December 13, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 48 skipping to change at page 2, line 48
4.1.2. Indirect Connection to the DWDM Management System 4.1.2. Indirect Connection to the DWDM Management System
(First Optical Node) . . . . . . . . . . . . . . . . 11 (First Optical Node) . . . . . . . . . . . . . . . . 11
4.2. Control Plane Considerations . . . . . . . . . . . . . . 13 4.2. Control Plane Considerations . . . . . . . . . . . . . . 13
4.2.1. Considerations Using GMPLS Signaling . . . . . . . . 14 4.2.1. Considerations Using GMPLS Signaling . . . . . . . . 14
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Service Setup . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Link Monitoring Use Cases . . . . . . . . . . . . . . . . 16 5.2. Link Monitoring Use Cases . . . . . . . . . . . . . . . . 16
5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 19 5.2.1. Pure Access Link (AL) Monitoring Use Case . . . . . . 19
5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 21 5.2.2. Power Control Loop Use Case . . . . . . . . . . . . . 21
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 29 Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The usage of external single channel Dense Wavelenght Division The usage of external single channel Dense Wavelenght Division
Multiplexing (DWDM) interfaces (e.g. in routers) connected to a DWDM Multiplexing (DWDM) interfaces (e.g. in routers) connected to a DWDM
Network (e.g. router connected to a network of Reconfigurable Optical Network (e.g. router connected to a network of Reconfigurable Optical
Add Drop Multiplexers (ROADM) and optical amplifiers) adds a further Add Drop Multiplexers (ROADM) and optical amplifiers) adds a further
networking option for operators but requires an harmonised control networking option for operators but requires an harmonised control
and management plane interaction between the different network and management plane interaction between the different network
domains. domains.
skipping to change at page 4, line 21 skipping to change at page 4, line 21
they appear in all capitals, as shown here. they appear in all capitals, as shown here.
While RFC 2119 [RFC2119] RFC 8174 [RFC8174] describe interpretations While RFC 2119 [RFC2119] RFC 8174 [RFC8174] describe interpretations
of these key words in terms of protocol specifications and of these key words in terms of protocol specifications and
implementations, they are used in this document to describe design implementations, they are used in this document to describe design
requirements for protocol extensions. requirements for protocol extensions.
2. Terminology and Definitions 2. Terminology and Definitions
The current generation of Wavelenght Division Multiplexing (WDM) The current generation of Wavelenght Division Multiplexing (WDM)
netwoks are single vendor networks where the optical line system and networks are single vendor networks where the optical line system and
the transponders are tightly integrated. The DWDM interface the transponders are tightly integrated. The DWDM interface
migration from integrated transponders to third party transponders or migration from integrated transponders to third party transponders or
colored interfaces change this scenario and introduces a standardized colored interfaces change this scenario and introduces a standardized
interface at the level of OCh between the DWDM interface and the DWDM interface at the level of OCh between the DWDM interface and the DWDM
network. network.
Black Link: The Black Link [ITU-T.G.698.2] allows supporting an Black Link: The Black Link [ITU-T.G.698.2] allows supporting an
optical transmitter/receiver pair (of a single vendor or from optical transmitter/receiver pair (of a single vendor or from
different vendors) to provide a single optical channel interface and different vendors) to provide a single optical channel interface and
transport it over an optical network composed of amplifiers, filters, transport it over an optical network composed of amplifiers, filters,
skipping to change at page 7, line 15 skipping to change at page 7, line 15
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 a set of parameter set for a certain set of example specifies a set of parameter set for a certain set of
applications. applications.
This document elaborates only the IaDI (Intra Domain Interface) as This document elaborates only the IaDI (Intra Domain Interface) as
shown in Figure 1 as DWDM transversely compatible and multi-vendor shown in Figure 1 as DWDM transversely compatible and multi-vendor
interface within one administrative domain controlled by the network interface within one administrative domain controlled by the network
operator. operator.
SNMP/Simple Management Interface (SMI), Netconf/Restcong and Link SNMP/Simple Management Interface (SMI), NETCONF/RESTCONF and Link
Management Protocol (LMP) TLV to support the direct exchange of Management Protocol (LMP) TLV to support the direct exchange of
information between the client and the network management and control information between the client and the network management and control
plane will be specified in further documents. plane will be specified in further documents.
IETF working groups are encouraged to use the NETCONF/YANG standards The YANG based NETCONF and RESTCONF protocol are better suited for
for configuration, especially in new charters. SNMP MIB modules creating and modifying configuration state and thus RECOMMENDED to be
creating and modifying configuration state should only be produced by used over SNMP MIB. The SNMP MIB creating and modifying
working groups in cases of clear utility and consensus to use SNMP configuration state could be used for legacy network.
write operations for configuration, and in consultation with the OPS
ADs/MIB doctors. The SNMP MIB creating and modifying configuration
state could be used for legacy network.
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. Among interfaces, multi-vendor interconnection can also be achieved. Among
the possible use cases, it may be used to remove the need for one the possible use cases, it may be used to remove the need for one
short reach transmitter and receiver pair per channel (eliminating short reach transmitter and receiver pair per channel (eliminating
the transponders). the transponders).
Figure 2 shows a set of reference points, for single-channel Figure 2 shows a set of reference points, for single-channel
skipping to change at page 9, line 5 skipping to change at page 9, 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.
SNMP/SMI, Netconf/Restconf and LMP TLV to support the direct exchange SNMP/SMI, NETCONF/RESTCONF and LMP TLV to support the direct exchange
of information between the client and the network management and of information between the client and the network management and
control plane will be specified in further documents. control 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 a hierarchical management system is used. single management system or a hierarchical management system is used.
Currently each WDM vendor provides an Element Management System (EMS) Currently each WDM vendor provides an Element Management System (EMS)
skipping to change at page 10, line 28 skipping to change at page 10, line 28
| NMS | | NMS |
|_____| |_____|
/_____/ /_____/
| |
| |
| |
+---+---+ +---+---+
+----->+ EMS | +----->+ EMS |
/ | | / | |
/ +-------+ / +-------+
/ | MI SNMP or Netconf/Restconf / | MI SNMP or NETCONF/RESTCONF
SNMP / or Netconf | DCN Network SNMP / or NETCONF | DCN Network
--------------------+------------------------------- --------------------+-------------------------------
/ +------+-----------------------+ / +------+-----------------------+
/ | +| WDM Domain + | / | +| WDM Domain + |
/ | |\ /| | / | |\ /| |
+---+--+ | | \ |\ / | | +------+ +---+--+ | | \ |\ / | | +------+
| CL |-/C------+-----|OM|----|/-------|OD|----+-------/C-| CL | | CL |-/C------+-----|OM|----|/-------|OD|----+-------/C-| CL |
| |-/C------+-----| |----- /|-----| |----+-------/C-| | | |-/C------+-----| |----- /|-----| |----+-------/C-| |
+------+ | | / \| \ | | +------+ +------+ | | / \| \ | | +------+
| |/ \| | | |/ \| |
| + + | | + + |
skipping to change at page 11, line 20 skipping to change at page 11, line 20
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 standardized way to enable interoperable solutions between in a standardized way to enable interoperable solutions between
different optical interface vendors and vendors of the optical different optical interface vendors and vendors of the optical
network management application. [RFC3591] defines managed objects network management application. [RFC3591] defines managed objects
for the optical interface type but needs further extension to cover for the optical interface type but needs further extension to cover
the optical parameters required by this framework document. the optical parameters required by this framework document.
Is to be noted that the CL (client device) and the DWDM network are Is to be noted that the CL (client device) and the DWDM network are
belonging to the same operator so the DWDM EMS and the Client devices belonging to the same operator so the DWDM EMS and the Client devices
are connected to the same DCN and the communication is not affected are connected to the same DCN and the communication security
by security issue. considerations are applicable to CL as per DWDM devices.
Note that a software update of the optical interface components of Note that a software update of the optical interface components of
the client nodes must not lead obligatory to an update of the the client nodes must not lead obligatory to an update of the
software of the EMS and vice versa. software of the EMS and vice versa.
4.1.2. Indirect Connection to the DWDM Management System (First Optical 4.1.2. Indirect Connection to the DWDM Management System (First Optical
Node) Node)
An alternative as shown in Figure 4 should be used in cases where a An alternative as shown in Figure 4 should be used in cases where a
more integrated relationship between transport node (e.g. OM or OD more integrated relationship between transport node (e.g. OM or OD
skipping to change at page 12, line 20 skipping to change at page 12, line 20
+-----+ +-----+
| NMS | | NMS |
|_____| |_____|
/_____/ /_____/
| |
| |
+---+---+ +---+---+
| EMS | | EMS |
| | | |
+-------+ +-------+
| MI SNMP or Netconf/Restconf | MI SNMP or NETCONF/RESTCONF
| |
LMP +------+-----------------------+ LMP +------+-----------------------+
+------------+---+ +| + | +------------+---+ +| + |
| | | |\ /| | | | | |\ /| |
+---+--+ | +-+ \ |\ / | | +------+ +---+--+ | +-+ \ |\ / | | +------+
| CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL | | CL |-/C------+--- -|OM|----|/-------|OD|--- +-------/C-| CL |
| |-/C------+--- -| |----- /|-----| |----+-------/C-| | | |-/C------+--- -| |----- /|-----| |----+-------/C-| |
+------+ | | / \| \ | | +------+ +------+ | | / \| \ | | +------+
| |/ \| | | |/ \| |
| + + | | + + |
skipping to change at page 22, line 44 skipping to change at page 22, line 44
| <--<|-------| / | | <--<|-------| / |
P(Rx) = P(out) - a(Rx) | |/ | P(Rx) = P(out) - a(Rx) | |/ |
| | | |
| ROADM | | ROADM |
+--------------------------+ +--------------------------+
Figure 7: Power control loop Figure 7: Power control loop
- The power control loop in transponders and ROADMs controls - The power control loop in transponders and ROADMs controls
the Variable Optical Attenuators (VOA) to adjust the proper the Variable Optical Attenuators (VOA) to adjust the proper
power in base of the ROADM and Receiver caracteristics and power in base of the ROADM and Receiver characteristics and
the Access Link attenuation the Access Link attenuation
6. Requirements 6. Requirements
Even if network architectures becomes more complex, management and Even if network architectures becomes more complex, management and
operation as well as the provisioning process should have a higher operation as well as the provisioning process should have a higher
degree of automation or should be fully automated. Simplifying and degree of automation or should be fully automated. Simplifying and
automating the entire management and provisioning process of the automating the entire management and provisioning process of the
network in combination with a higher link utilization and faster network in combination with a higher link utilization and faster
restoration times will be the major requirements that have been restoration times will be the major requirements that have been
skipping to change at page 24, line 17 skipping to change at page 24, line 17
channel optical interface). The Procedure MAY me defined in a channel optical interface). The Procedure MAY me defined in a
dedicated draft as proposed in Appendix. dedicated draft as proposed in Appendix.
2 In order to ensure a lean management and provisioning of single 2 In order to ensure a lean management and provisioning of single
channel interfaces, the management and control plane of both the channel interfaces, the management and control plane of both the
client and DWDM network MUST be aware of the right set of client and DWDM network MUST be aware of the right set of
parameters. Such parameters define the interfaces and the optical parameters. Such parameters define the interfaces and the optical
network and are needed to properly setup the optical connection. network and are needed to properly setup the optical connection.
3 A standard-based northbound API (to network management system) 3 A standard-based northbound API (to network management system)
based on Netconf/Restconf SHOULD be supported, alternatively SNMP based on NETCONF/RESTCONF SHOULD be supported, alternatively SNMP
MAY be supported too. MAY be supported too.
4 A standard-based data model for single channel interfaces MUST be 4 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.
5 Netconf SHOULD be used also for configuration of the single 5 NETCONF SHOULD be used also for configuration of the single
channel interfaces including the power setting channel interfaces including the power setting
6 LMP SHOULD be extended and used in cases where optical 6 LMP SHOULD be extended and used in cases where optical
parameters need to be exchanged between two nodes to correlate parameters need to be exchanged between two 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. The LMP extension MAY be defined in a draft channel interface. The LMP extension MAY be defined in a draft
as reported in Appendix. as reported in Appendix.
7 LMP MAY be used to adjust the output power of the single 7 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.
8 RSVP-TE SHOULD be used to exchange some relevant parameters 8 RSVP-TE SHOULD be used to exchange some relevant parameters
between the client and the optical node (e.g. the label value), between the client and the optical node (e.g. the label value),
without preventing the network to remain in charge of the optical without preventing the network to remain in charge of the optical
path computation path computation
9 Power monitoring functions at both ends of the DWDM connection 9 Power monitoring functions at both ends of the DWDM connection
MAY be used to further automate the setup and shoutdown MAY be used to further automate the setup and shutdown
process of the optical interfaces. process of the optical interfaces.
10 In fault cases, the network SHOULD be able to recover wavelengths, 10 In fault cases, the network SHOULD be able to recover wavelengths,
either using pre-defined paths or dynamic re-routing. either using pre-defined paths or dynamic re-routing.
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. Appendix 7. Acknowledgements
In this section are reported some examples and references on the MIB,
Yang and LMP usage. The MIB and TLV defining the parameters
described above are reported in the drafts below and are intended as
informative data:
draft-dharinigert-ccamp-dwdm-if-lmp
Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for
Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems
to manage the application code of optical interface parameters in
DWDM application
draft-ggalimbe-ccamp-flex-if-lmp
Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for
Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems
to manage the application code of optical interface parameters in
DWDM application
draft-dharini-ccamp-dwdm-if-param-yang
A YANG model to manage the optical interface parameters for an
external transponder in a WDM network
draft-ietf-ccamp-flexigrid-yang
YANG data model for Flexi-Grid Optical Networks
draft-galimbe-ccamp-iv-yang
A YANG model to manage the optical parameters for in a WDM network
8. 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.
9. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Security Considerations 9. Security Considerations
The architecture and solution space in scope of this framework The architecture and solution space in scope of this framework
imposes no additional requirements to the security models already imposes no additional requirements to the security models already
defined in RFC5920 for packet/optical networks using GMPLS, covering defined in RFC5920 for packet/optical networks using GMPLS, covering
also Control Plane and Management interfaces. Respective security also Control Plane and Management interfaces. Respective security
mechanisms of the components and protocols, e.g. LMP security mechanisms of the components and protocols, e.g. LMP security
models, can be applied unchanged. models, can be applied unchanged.
As this framework is focusing on the single operator use case, the As this framework is focusing on the single operator use case, the
security concerns can be relaxed to a subset compared to a setup security concerns can be relaxed to a subset compared to a setup
skipping to change at page 26, line 18 skipping to change at page 25, line 36
external interfaces. external interfaces.
Concerning the access control to Management interfaces, security Concerning the access control to Management interfaces, security
issues can be generally addressed by authentication techniques issues can be generally addressed by authentication techniques
providing origin verification, integrity and confidentiality. providing origin verification, integrity and confidentiality.
Additionally, access to Management interfaces can be physically or Additionally, access to Management interfaces can be physically or
logically isolated, by configuring them to be only accessible out-of- logically isolated, by configuring them to be only accessible out-of-
band, through a system that is physically or logically separated from band, through a system that is physically or logically separated from
the rest of the network infrastructure. In case where management the rest of the network infrastructure. In case where management
interfaces are accessible in-band at the client device or within the interfaces are accessible in-band at the client device or within the
optical transport netork domain, filtering or firewalling techniques optical transport network 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.
11. Contributors 10. Contributors
Arnold Mattheus Arnold Mattheus
Deutsche Telekom Deutsche Telekom
Darmstadt Darmstadt
Germany Germany
email arnold.Mattheus@telekom.de email arnold.Mattheus@telekom.de
Manuel Paul Manuel Paul
Deutsche Telekom Deutsche Telekom
Berlin Berlin
Germany Germany
skipping to change at page 27, line 35 skipping to change at page 26, line 35
Germany Germany
email Frank.Luennemann@telekom.de email Frank.Luennemann@telekom.de
Dharini Hiremagalur Dharini Hiremagalur
Juniper Juniper
1133 Innovation Way 1133 Innovation Way
Sunnyvale - 94089 California Sunnyvale - 94089 California
USA USA
dharinih@juniper.net dharinih@juniper.net
12. References 11. References
12.1. Normative References 11.1. Normative References
[ITU-T.G.694.1] [ITU-T.G.694.1]
International Telecommunications Union, "Spectral grids International Telecommunications Union, "Spectral grids
for WDM applications: DWDM frequency grid", for WDM applications: DWDM frequency grid",
ITU-T Recommendation G.694.1, Febriary 2012. ITU-T Recommendation G.694.1, Febriary 2012.
[ITU-T.G.698.2] [ITU-T.G.698.2]
International Telecommunications Union, "Amplified International Telecommunications Union, "Amplified
multichannel dense wavelength division multiplexing multichannel dense wavelength division multiplexing
applications with single channel optical interfaces", applications with single channel optical interfaces",
skipping to change at page 29, line 16 skipping to change at page 28, line 16
and D. Ceccarelli, "RSVP-TE Signaling Extensions in and D. Ceccarelli, "RSVP-TE Signaling Extensions in
Support of Flexi-Grid Dense Wavelength Division Support of Flexi-Grid Dense Wavelength Division
Multiplexing (DWDM) Networks", RFC 7792, Multiplexing (DWDM) Networks", RFC 7792,
DOI 10.17487/RFC7792, March 2016, DOI 10.17487/RFC7792, March 2016,
<https://www.rfc-editor.org/info/rfc7792>. <https://www.rfc-editor.org/info/rfc7792>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 11.2. Informative References
[ITU-T.G.691] [ITU-T.G.691]
ITU-T, "Optical interfaces for single channel STM-64 and ITU-T, "Optical interfaces for single channel STM-64 and
other SDH systems with optical amplifiers", other SDH systems with optical amplifiers",
ITU-T Recommendation ITU-T G.691, 2008. ITU-T Recommendation ITU-T G.691, 2008.
[ITU-T.G.693] [ITU-T.G.693]
ITU-T, "Optical interfaces for intra-office systems", ITU-T, "Optical interfaces for intra-office systems",
ITU-T Recommendation ITU-T G.693, 2009. ITU-T Recommendation ITU-T G.693, 2009.
skipping to change at page 30, line 5 skipping to change at page 29, line 5
that enables the network to assign an upstream label for a that enables the network to assign an upstream label for a
bidirectional LSP", draft-ietf-teas-network-assigned- bidirectional LSP", draft-ietf-teas-network-assigned-
upstream-label draft-ietf-teas-network-assigned-upstream- upstream-label draft-ietf-teas-network-assigned-upstream-
label, June 2017. label, June 2017.
[RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support [RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support
Operation of MPLS-TE over GMPLS Networks", RFC 5146, Operation of MPLS-TE over GMPLS Networks", RFC 5146,
DOI 10.17487/RFC5146, March 2008, DOI 10.17487/RFC5146, March 2008,
<https://www.rfc-editor.org/info/rfc5146>. <https://www.rfc-editor.org/info/rfc5146>.
Appendix A. Appendix
In this section are reported some examples and references on the MIB,
Yang and LMP usage. The MIB and TLV defining the parameters
described above are reported in the drafts below and are intended as
informative data:
draft-dharinigert-ccamp-dwdm-if-lmp
Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for
Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems
to manage the application code of optical interface parameters in
DWDM application
draft-ggalimbe-ccamp-flex-if-lmp
Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for
Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems
to manage the application code of optical interface parameters in
DWDM application
draft-dharini-ccamp-dwdm-if-param-yang
A YANG model to manage the optical interface parameters for an
external transponder in a WDM network
draft-ietf-ccamp-flexigrid-yang
YANG data model for Flexi-Grid Optical Networks
draft-galimbe-ccamp-iv-yang
A YANG model to manage the optical parameters for in a WDM network
NOTE: the above information is defined at the time of publication of
this document and thus subject to change.
Authors' Addresses Authors' Addresses
Ruediger Kunze (editor) Ruediger Kunze (editor)
Deutsche Telekom Deutsche Telekom
Winterfeldtstr. 21-27 Winterfeldtstr. 21-27
10781 Berlin 10781 Berlin
Germany Germany
Phone: +491702275321 Phone: +491702275321
Email: RKunze@telekom.de Email: RKunze@telekom.de
 End of changes. 25 change blocks. 
69 lines changed or deleted 69 lines changed or added

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