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-ietf-ccamp-dwdm-if-lmp-05
| Document | Type | Active Internet-Draft (ccamp WG) | |
|---|---|---|---|
| Authors | Dharini Hiremagalur , Gert Grammel , Gabriele Galimberti , Ruediger Kunze , Dieter Beller | ||
| Last updated | 2021-12-28 | ||
| Replaces | draft-dharinigert-ccamp-dwdm-if-lmp | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | WG state | WG Document | |
| Associated WG milestone |
|
||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-ccamp-dwdm-if-lmp-05
Internet Engineering Task Force D. Hiremagalur, Ed.
Internet-Draft G. Grammel, Ed.
Intended status: Standards Track Juniper
Expires: July 1, 2022 G. Galimberti, Ed.
Cisco
R. Kunze, Ed.
Deutsche Telekom
D. Beller
Nokia
December 28, 2021
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-ietf-ccamp-dwdm-if-lmp-05
Abstract
This memo defines extensions to LMP [RFC4209] for managing Optical
parameters associated with Wavelength Division Multiplexing (WDM)
systems in accordance with the Interface Application Identifier
approach defined in ITU-T Recommendation G.694.1.[ITU-T.G694.1] and
its extensions.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
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 https://datatracker.ietf.org/drafts/current/.
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 July 1, 2022.
Hiremagalur, et al. Expires July 1, 2022 [Page 1]
Internet-Draft draft-ietf-ccamp-dwdm-if-lmp-05 December 2021
Copyright Notice
Copyright (c) 2021 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
(https://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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. DWDM line system . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Optical interface parameter collection . . . . . . . . . 4
3.2. DWDM client - ROADM interconection discovery . . . . . . 5
3.3. Service Setup . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Link Monitoring Use Cases . . . . . . . . . . . . . . . . 6
4. Extensions to LMP-WDM Protocol . . . . . . . . . . . . . . . 7
5. General Parameters - OCh_General . . . . . . . . . . . . . . 7
6. ApplicationIdentifier - OCh_ApplicationIdentifier . . . . . . 9
7. OCh_Ss - OCh transmit parameters . . . . . . . . . . . . . . 11
8. OCh_Rs - receive parameters . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
LMP [RFC4209] provides link property correlation capabilities that
can be used between a transceiver device and an Optical Line System
(OLS) device. Link property correlation is a procedure by which,
intrinsic parameters and capabilities are exchanged between two ends
of a link. Link property correlation as defined in RFC3591 allows
either end of the link to supervise the received signal and operate
within a commonly understood parameter window. Here the term 'link'
refers in particular to the attachment link between OXC and OLS (see
Figure 1). The relevant interface parameters are in line with
Hiremagalur, et al. Expires July 1, 2022 [Page 2]
Internet-Draft draft-ietf-ccamp-dwdm-if-lmp-05 December 2021
"draft-ietf-ccamp-dwdm-if-param-yang". Use cases are 1- Optical
interface parameter collection, 2- DWDM client - ROADM interconection
discovery, 3- Service Setup, 4- Link Monitoring
2. DWDM line system
Figure 1 shows a set of reference points (Rs and Ss), for a single-
channel connection between transmitter (Tx) and receiver (Rx)
devices. Here the DWDM network elements in between those devices
include an Optical Multiplexer (OM) and an Optical Demultiplexer
(OD). In addition it may include one or more Optical Amplifiers (OA)
and one or more Optical Add-Drop Multiplexers (OADM).
+-------------------------------------------------+
Ss | DWDM Network Elements | Rs
+--+ | | | \ / | | | +--+
Tx L1--|->| \ +------+ +------+ / |--|-->Rx L1
+---+ | | | | | +------+ | | | | | +--+
+---+ | | | | | | | | | | | | +--+
Tx L2--|->| OM |-->|------|->|ROADM |--|------|->| OD |--|-->Rx L2
+---+ | | | | | | | | | | | | +--+
+---+ | | | | | +------+ | | | | | +--+
Tx L3--|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3
+---+ | | / | Link +----|--|----+ Link | \ | | +--+
+-----------+ | | +----------+
+--+ +--+
| |
Rs v | Ss
+-----+ +-----+
|RxLx | |TxLx |
+-----+ +-----+
Ss = Sender reference point at the DWDM network element
tributary output
Rs = Receiver reference point at the DWDM network element
tributary input
Lx = Lambda x
OM = Optical Mux
OD = Optical Demux
ROADM = Reconfigurable Optical Add Drop Mux
from Fig. 5.1/G.698.2
Figure 1: Linear Single Channel approach
Hiremagalur, et al. Expires July 1, 2022 [Page 3]
Internet-Draft draft-ietf-ccamp-dwdm-if-lmp-05 December 2021
Figure 2 Extended LMP Model ( from [RFC4209] )
+------+ Ss +------+ +------+ Rs +------+
| | ----- | | | | ----- | |
| OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
| | ----- | | | | ----- | |
+------+ +------+ +------+ +------+
^ ^ ^ ^ ^ ^
| | | | | |
| +-----LMP-----+ +-----LMP-----+ |
| |
+----------------------LMP-----------------------+
OXC : is an entity that contains transponders
OLS : generic optical system, it can be -
Optical Mux, Optical Demux, Optical Add
Drop Mux, Amplifier etc.
OLS to OLS : represents the Optical Multiplex section
<xref target="ITU-T.G709"/>
Rs/Ss : reference points in between the OXC and the OLS
Figure 2: Extended LMP Model
3. Use Cases
A comparison with the traditional operation scenarios provides an
insight of similarities and distinctions in operation and management
of DWDM interfaces. The following use cases provide an overview
about operation and maintenance processes.
3.1. Optical interface parameter collection
It is necessary to identify the Optical interface characteristics and
setting in order to properly calculate the ent to end path and match
the Head End interface against the Tail End interface compatibility.
The optical parameters may have multiple possible values that the
Controller (SDN or GMPLS) can use and select for the best network
optimisation. In case og GMPLS the LMP is suitable to support the
parameters exchange between the ROADM and the Transponder (or DWDM
interface located into the client box).
Hiremagalur, et al. Expires July 1, 2022 [Page 4]
Internet-Draft draft-ietf-ccamp-dwdm-if-lmp-05 December 2021
3.2. DWDM client - ROADM interconection discovery
Being the DWDM port (Rs and Ss) and ROADM port belonging to different
domains and Network Elements, the interconnection between them is not
embedded in the Optical Nodes (OLS layer) and can not be shared to
the EMS and the Controller. The Controller needs then to retrieve
the connectivity using data coming from the two domains correlating
them to discover the relationship. The methods to discover the
interconnection can be LMP, LLDP, installation provisioning or any
other mechanism using the light (or power) transmitted by the DWDM
transmitter and detecter by the ROAMD port photodiode. This use case
is fundamental to build the interconnections between the DWDM and
Client layer (e.g. Routers) and re-build the multilayer network
topology.
3.3. Service Setup
It is necessary to differentiate between different operational issues
for setting up a light path (a DWDM connection is specific in having
defined maximum impairments) within an operational network.
The first step is to determine if transceivers located at different
end-points are interoperable, i.e. support a common set of
operational parameters. In this step it is required to determine
transceiver capabilities in a way to be able to correlate them for
interoperability purposes. Such parameters include modulation
scheme, modulation parameters, FEC to name a few. If both
transceivers are controlled by the same NMS or Control Plane, such
data is readily available. However in cases where the transceivers
are controlled by different CP, a protocol needs to be used to inform
the controlling instance (NMS or CP) about transceiver parameters.
It is suggested to extend LMP for that purpose.
The second step is to determine the feasibility of a lightpath
between two transceivers without applying an optical signal.
Understanding the limitations of the transceiver pair, a path through
the optical network has to be found, whereby each path has an
individual set of impairments deteriorating a wavelength traveling
along that path. Since a single transceiver can support multiple
parameter sets, the selection of a path may limit the permissible
parameter sets determined in previous steps.
The third step is then to setup the connection itself and to
determine the Wavelength. This is done using the NMS of the optical
transport network or by means of a control plane interaction such as
signaling and includes the path information as well as the parameter
set information necessary to enable communication.
Hiremagalur, et al. Expires July 1, 2022 [Page 5]
Internet-Draft draft-ietf-ccamp-dwdm-if-lmp-05 December 2021
In a fourth step, optical monitoring is activated in the WDM network
in order to monitor the status of the connection. The monitor
functions of the optical interfaces at the terminals are also
activated in order to monitor the end to end connection.
Furthermore it should be possible to automate this step. After
connecting the client device to the neighbor control plane-enabled
transport node, a control adjacency may be automatically established,
e.g. using LMP.
3.4. Link Monitoring Use Cases
The use cases described below are assuming that power monitoring
functions are available in the ingress and egress network element of
the DWDM network, respectively. By performing link property
correlation it would be beneficial to include the current transmit
power value at reference point Ss and the current received power
value at reference point Rs. For example if the Client transmitter
power has a value of 0dBm and the ROADM interface measured power is
-6dBm the fiber patch cord connecting the two nodes may be pinched or
the connectors are dirty. As discussed before, the actual path or
selection of a specific wavelength within the allowed set is outside
the scope of LMP. The computing entities (e.g. the first optical
node originating the circuit) can rely on GMPLS IGP (OSPF) to
retrieve all the information related to the network, calculate the
path to reach the endpoint and signal the path implementation through
the network via RSVP-TE.
[ITU-T.G.698.2] defines a single channel optical interface for DWDM
systems that allows interconnecting network-external optical
transponders across a DWDM network. The optical transponders are
external to the DWDM network. This so-called 'Black Link' approach
illustrated in Fig. 5-1 of [ITU-T.G.698.2]. The single channel fiber
link between the Ss/Rs reference points and the ingress/egress port
of the network element on the domain boundary of the DWDM network
(DWDM border NE) is called access link. Based on the definition in
[ITU-T.G.698.2] it is part of the DWDM network. The access link is
typically realized as a passive fiber link that has a specific
optical attenuation (insertion loss). As the access link is an
integral part of the DWDM network, it is desirable to monitor its
attenuation. Therefore, it is useful to detect an increase of the
access link attenuation, for example, when the access link fiber has
been disconnected and reconnected (maintenance) and a bad patch panel
connection (connector) resulted in a significantly higher access link
attenuation (loss of signal in the extreme case of an open connector
or a fiber cut). In the following section, two use cases are
presented and discussed:
Hiremagalur, et al. Expires July 1, 2022 [Page 6]
Internet-Draft draft-ietf-ccamp-dwdm-if-lmp-05 December 2021
1) pure access link monitoring
2) access link monitoring with a power control loop
These use cases require a power monitor as described in G.697 (see
section 6.1.2), that is capable to measure the optical power of the
incoming or outgoing single channel signal. The use case where a
power control loop is in place could even be used to compensate an
increased attenuation if the optical transmitter can still be
operated within its output power range defined by its application
code.
4. Extensions to LMP-WDM Protocol
This document defines extensions to [RFC4209] to allow a set of
characteristic parameters, to be exchanged between a router or
optical switch (e.g. OTN cross connect) and the optical line system
to which it is attached. In particular, this document defines
additional Data Link sub-objects to be carried in the LinkSummary
message defined in [RFC4204] and [RFC6205]. The OXC and OLS systems
may be managed by different Network management systems and hence may
not know the capability and status of their peer. These messages and
their usage are defined in subsequent sections of this document.
The following new messages are defined for the WDM extension for
ITU-T G.698.2 [ITU-T.G698.2]/ITU-T G.698.1 [ITU-T.G698.1]/
ITU-T G.959.1 [ITU-T.G959.1]
- OCh_General (sub-object Type = TBA)
- OCh_ApplicationIdentier (sub-object Type = TBA)
- OCh_Ss (sub-object Type = TBA)
- OCh_Rs (sub-object Type = TBA)
5. General Parameters - OCh_General
These are a set of general parameters as described in [G698.2] and
[G.694.1]. Please refer to the "draft-ietf-ccamp-dwdm-if-param-yang"
for more details about these parameters and the [RFC6205] for the
wavelength definition.
The general parameters are
1. Central Frequency - (Tera Hz) 4 bytes (see RFC6205 sec.3.2)
2. Number of Application Identifiers (A.I.) Supported
3. Single-channel Application Identifier in use
4. Application Identifier Type in use
5. Application Identifier in use
Figure 3: The format of the this sub-object (Type = TBA, Length =
TBA) is as follows:
Hiremagalur, et al. Expires July 1, 2022 [Page 7]
Internet-Draft draft-ietf-ccamp-dwdm-if-lmp-05 December 2021
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Central Frequency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Application | |
| Identifiers Supported | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel| A.I. Type | A.I. length |
| Application | in use | |
| Identifier | | |
| Number in use | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel Application Identifier in use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel Application Identifier in use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel Application Identifier in use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.I. Type in use: STANDARD, PROPRIETARY
A.I. Type in use: STANDARD
Refers to G.698.2 recommendation (e.g.) : B-DScW-ytz(v)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel Application Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel Application Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel Application Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.I. Type in use: PROPRIETARY
Note: if the A.I. type = PROPRIETARY, the first 6 Octets of the
Application Identifier in use are six characters of the
PrintableString must contain the Hexadecimal representation of
an OUI (Organizationally Unique Identifier) assigned to the
vendor whose implementation generated the Application
Identifier; the remaining octets of the PrintableString are
Hiremagalur, et al. Expires July 1, 2022 [Page 8]
Internet-Draft draft-ietf-ccamp-dwdm-if-lmp-05 December 2021
unspecified.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI cont. | Vendor value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: OCh_General
6. ApplicationIdentifier - OCh_ApplicationIdentifier
This message is to exchange the application identifiers supported as
described in [G698.2]. There can be more than one Application
Identifier supported by the transmitter/receiver in the OXC. The
number of application identifiers supported is exchanged in the
"OCh_General" message. (from [G698.1]/[G698.2]/[G959.1] and G.874.1)
The parameters are:
1. Number of Application Identifiers (A.I.) Supported
2. Single-channel application identifier Number
uniquely identifiers this entry - 8 bits
3. Application Indentifier Type (A.I.) (STANDARD/PROPRIETARY)
4. Single-channel application identifier -- 96 bits
(from [G698.1]/[G698.2]/[G959.1]
- this parameter can have
multiple instances as the transceiver can support multiple
application identifiers.
Figure 4: The format of the this sub-object (Type = TBA, Length =
TBA) is as follows:
0 1 2 3
Hiremagalur, et al. Expires July 1, 2022 [Page 9]
Internet-Draft draft-ietf-ccamp-dwdm-if-lmp-05 December 2021
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Application | |
| Identifiers Supported | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel| A.I. Type | A.I. length |
| Application | | |
| Identifier | | |
| Number | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel Application Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel Application Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel Application Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// .... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel| | A.I. length |
| Application | A.I. Type | |
| Identifier | | |
| Number | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel Application Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel Application Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel Application Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.I. Type in use: STANDARD, PROPRIETARY
A.I. Type in use: STANDARD
Refers to G.698.2 recommendation : B-DScW-ytz(v)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel Application Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel Application Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Single-channel Application Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hiremagalur, et al. Expires July 1, 2022 [Page 10]
Internet-Draft draft-ietf-ccamp-dwdm-if-lmp-05 December 2021
A.I. Type in use: PROPRIETARY
Note: if the A.I. type = PROPRIETARY, the first 6 Octets of the
Application Identifier in use are six characters of the
PrintableString must contain the Hexadecimal representation of
an OUI (Organizationally Unique Identifier) assigned to the
vendor whose implementation generated the Application
Identifier; the remaining octets of the PrintableString are
unspecified.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI cont. | Vendor value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: OCh_ApplicationIdentifier
7. OCh_Ss - OCh transmit parameters
These are the G.698.2 parameters at the Source(Ss reference points).
Please refer to "draft-ietf-ccamp-dwdm-if-param-yang" for more
details about these parameters.
1. Output power
Figure 5: The format of the OCh sub-object (Type = TBA, Length = TBA)
is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Power |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: OCh_Ss transmit parameters
Hiremagalur, et al. Expires July 1, 2022 [Page 11]
Internet-Draft draft-ietf-ccamp-dwdm-if-lmp-05 December 2021
8. OCh_Rs - receive parameters
These are the G.698.2 parameters at the Sink (Rs reference points).
1. Current Input Power - (0.1dbm) 4bytes
Figure 6: The format of the OCh receive sub-object (Type = TBA,
Length = TBA) is as follows:
The format of the OCh receive/OLS Sink sub-object (Type = TBA,
Length = TBA) is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Input Power |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: OCh_Rs receive parameters
9. Security Considerations
LMP message security uses IPsec, as described in [RFC4204]. This
document only defines new LMP objects that are carried in existing
LMP messages, similar to the LMP objects in [RFC:4209]. This
document does not introduce new security considerations.
10. IANA Considerations
Hiremagalur, et al. Expires July 1, 2022 [Page 12]
Internet-Draft draft-ietf-ccamp-dwdm-if-lmp-05 December 2021
LMP <xref target="RFC4204"/> defines the following name spaces and
the ways in which IANA can make assignments to these namespaces:
- LMP Message Type
- LMP Object Class
- LMP Object Class type (C-Type) unique within the Object Class
- LMP Sub-object Class type (Type) unique within the Object Class
This memo introduces the following new assignments:
LMP Sub-Object Class names:
under DATA_LINK Class name (as defined in <xref target="RFC4204"/>)
- OCh_General (sub-object Type = TBA)
- OCh_ApplicationIdentifier (sub-object Type = TBA)
- OCh_Ss (sub-object Type = TBA)
- OCh_Rs (sub-object Type = TBA)
11. Contributors
Arnold Mattheus
Deutsche Telekom
Darmstadt
Germany
email a.mattheus@telekom.de
John E. Drake
Juniper
1194 N Mathilda Avenue
HW-US,Pennsylvania
USA
jdrake@juniper.net
Zafar Ali
Cisco
3000 Innovation Drive
KANATA
ONTARIO K2K 3E8
zali@cisco.com
12. References
Hiremagalur, et al. Expires July 1, 2022 [Page 13]
Internet-Draft draft-ietf-ccamp-dwdm-if-lmp-05 December 2021
12.1. Normative References
[ITU-T.G.698.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-T.G694.1]
International Telecommunications Union, ""Spectral grids
for WDM applications: DWDM frequency grid"",
ITU-T Recommendation G.698.2, February 2012.
[ITU-T.G709]
International Telecommunications Union, "Interface for the
Optical Transport Network (OTN)", ITU-T Recommendation
G.709, June 2016.
[ITU-T.G872]
International Telecommunications Union, "Architecture of
optical transport networks", ITU-T Recommendation G.872,
January 2017.
[ITU-T.G874.1]
International Telecommunications Union, "Optical transport
network (OTN): Protocol-neutral management information
model for the network element view", ITU-T Recommendation
G.874.1, November 2016.
[RFC4054] Strand, J., Ed. and A. Chiu, Ed., "Impairments and Other
Constraints on Optical Layer Routing", RFC 4054,
DOI 10.17487/RFC4054, May 2005,
<https://www.rfc-editor.org/info/rfc4054>.
[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
Protocol (LMP) for Dense Wavelength Division Multiplexing
(DWDM) Optical Line Systems", RFC 4209,
DOI 10.17487/RFC4209, October 2005,
<https://www.rfc-editor.org/info/rfc4209>.
[RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for
Lambda-Switch-Capable (LSC) Label Switching Routers",
RFC 6205, DOI 10.17487/RFC6205, March 2011,
<https://www.rfc-editor.org/info/rfc6205>.
Hiremagalur, et al. Expires July 1, 2022 [Page 14]
Internet-Draft draft-ietf-ccamp-dwdm-if-lmp-05 December 2021
12.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<https://www.rfc-editor.org/info/rfc2629>.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410,
DOI 10.17487/RFC3410, December 2002,
<https://www.rfc-editor.org/info/rfc3410>.
[RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of
MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181,
September 2005, <https://www.rfc-editor.org/info/rfc4181>.
Authors' Addresses
Dharini Hiremagalur (editor)
Juniper
1194 N Mathilda Avenue
Sunnyvale - 94089 California
USA
Phone: +1408
Email: dharinih@juniper.net
Gert Grammel (editor)
Juniper
Oskar-Schlemmer Str. 15
80807 Muenchen
Germany
Phone: +49 1725186386
Email: ggrammel@juniper.net
Gabriele Galimberti (editor)
Cisco
Via S. Maria Molgora, 48 c
20871 - Vimercate
Italy
Phone: +390392091462
Email: ggalimbe@cisco.com
Hiremagalur, et al. Expires July 1, 2022 [Page 15]
Internet-Draft draft-ietf-ccamp-dwdm-if-lmp-05 December 2021
Ruediger Kunze (editor)
Deutsche Telekom
Winterfeldtstr. 21-27
10781 Berlin
Germany
Phone: +491702275321
Email: RKunze@telekom.de
Dieter Beller
Nokia
Lorenzstrasse, 10
70435 Stuttgart
Germany
Phone: +4971182143125
Email: Dieter.Beller@nokia.com
Hiremagalur, et al. Expires July 1, 2022 [Page 16]