idnits 2.17.1
draft-ietf-ccamp-dwdm-if-lmp-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The abstract seems to contain references ([RFC4209], [ITU-T.G694.1]),
which it shouldn't. Please replace those with straight textual mentions
of the documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (December 28, 2021) is 843 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'ITU-T.G959.1' is mentioned on line 303, but not
defined
== Missing Reference: 'G.694.1' is mentioned on line 312, but not defined
== Unused Reference: 'ITU-T.G709' is defined on line 587, but no explicit
reference was found in the text
== Unused Reference: 'ITU-T.G872' is defined on line 592, but no explicit
reference was found in the text
== Unused Reference: 'ITU-T.G874.1' is defined on line 597, but no explicit
reference was found in the text
== Unused Reference: 'RFC4054' is defined on line 603, but no explicit
reference was found in the text
== Unused Reference: 'RFC2629' is defined on line 625, but no explicit
reference was found in the text
== Unused Reference: 'RFC3410' is defined on line 629, but no explicit
reference was found in the text
== Unused Reference: 'RFC4181' is defined on line 635, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T.G.698.2'
-- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T.G694.1'
-- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T.G709'
-- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T.G872'
-- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T.G874.1'
** Downref: Normative reference to an Informational RFC: RFC 4054
-- Obsolete informational reference (is this intentional?): RFC 2629
(Obsoleted by RFC 7749)
Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force D. Hiremagalur, Ed.
3 Internet-Draft G. Grammel, Ed.
4 Intended status: Standards Track Juniper
5 Expires: July 1, 2022 G. Galimberti, Ed.
6 Cisco
7 R. Kunze, Ed.
8 Deutsche Telekom
9 D. Beller
10 Nokia
11 December 28, 2021
13 Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense
14 Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage
15 the application code of optical interface parameters in DWDM application
16 draft-ietf-ccamp-dwdm-if-lmp-05
18 Abstract
20 This memo defines extensions to LMP [RFC4209] for managing Optical
21 parameters associated with Wavelength Division Multiplexing (WDM)
22 systems in accordance with the Interface Application Identifier
23 approach defined in ITU-T Recommendation G.694.1.[ITU-T.G694.1] and
24 its extensions.
26 Copyright Notice
28 Copyright (c) 2011 IETF Trust and the persons identified as the
29 document authors. All rights reserved.
31 Status of This Memo
33 This Internet-Draft is submitted in full conformance with the
34 provisions of BCP 78 and BCP 79.
36 Internet-Drafts are working documents of the Internet Engineering
37 Task Force (IETF). Note that other groups may also distribute
38 working documents as Internet-Drafts. The list of current Internet-
39 Drafts is at https://datatracker.ietf.org/drafts/current/.
41 Internet-Drafts are draft documents valid for a maximum of six months
42 and may be updated, replaced, or obsoleted by other documents at any
43 time. It is inappropriate to use Internet-Drafts as reference
44 material or to cite them other than as "work in progress."
46 This Internet-Draft will expire on July 1, 2022.
48 Copyright Notice
50 Copyright (c) 2021 IETF Trust and the persons identified as the
51 document authors. All rights reserved.
53 This document is subject to BCP 78 and the IETF Trust's Legal
54 Provisions Relating to IETF Documents
55 (https://trustee.ietf.org/license-info) in effect on the date of
56 publication of this document. Please review these documents
57 carefully, as they describe your rights and restrictions with respect
58 to this document. Code Components extracted from this document must
59 include Simplified BSD License text as described in Section 4.e of
60 the Trust Legal Provisions and are provided without warranty as
61 described in the Simplified BSD License.
63 Table of Contents
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. DWDM line system . . . . . . . . . . . . . . . . . . . . . . 3
67 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
68 3.1. Optical interface parameter collection . . . . . . . . . 4
69 3.2. DWDM client - ROADM interconection discovery . . . . . . 5
70 3.3. Service Setup . . . . . . . . . . . . . . . . . . . . . . 5
71 3.4. Link Monitoring Use Cases . . . . . . . . . . . . . . . . 6
72 4. Extensions to LMP-WDM Protocol . . . . . . . . . . . . . . . 7
73 5. General Parameters - OCh_General . . . . . . . . . . . . . . 7
74 6. ApplicationIdentifier - OCh_ApplicationIdentifier . . . . . . 9
75 7. OCh_Ss - OCh transmit parameters . . . . . . . . . . . . . . 11
76 8. OCh_Rs - receive parameters . . . . . . . . . . . . . . . . . 12
77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
79 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
81 12.1. Normative References . . . . . . . . . . . . . . . . . . 14
82 12.2. Informative References . . . . . . . . . . . . . . . . . 15
83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
85 1. Introduction
87 LMP [RFC4209] provides link property correlation capabilities that
88 can be used between a transceiver device and an Optical Line System
89 (OLS) device. Link property correlation is a procedure by which,
90 intrinsic parameters and capabilities are exchanged between two ends
91 of a link. Link property correlation as defined in RFC3591 allows
92 either end of the link to supervise the received signal and operate
93 within a commonly understood parameter window. Here the term 'link'
94 refers in particular to the attachment link between OXC and OLS (see
95 Figure 1). The relevant interface parameters are in line with
96 "draft-ietf-ccamp-dwdm-if-param-yang". Use cases are 1- Optical
97 interface parameter collection, 2- DWDM client - ROADM interconection
98 discovery, 3- Service Setup, 4- Link Monitoring
100 2. DWDM line system
102 Figure 1 shows a set of reference points (Rs and Ss), for a single-
103 channel connection between transmitter (Tx) and receiver (Rx)
104 devices. Here the DWDM network elements in between those devices
105 include an Optical Multiplexer (OM) and an Optical Demultiplexer
106 (OD). In addition it may include one or more Optical Amplifiers (OA)
107 and one or more Optical Add-Drop Multiplexers (OADM).
109 +-------------------------------------------------+
110 Ss | DWDM Network Elements | Rs
111 +--+ | | | \ / | | | +--+
112 Tx L1--|->| \ +------+ +------+ / |--|-->Rx L1
113 +---+ | | | | | +------+ | | | | | +--+
114 +---+ | | | | | | | | | | | | +--+
115 Tx L2--|->| OM |-->|------|->|ROADM |--|------|->| OD |--|-->Rx L2
116 +---+ | | | | | | | | | | | | +--+
117 +---+ | | | | | +------+ | | | | | +--+
118 Tx L3--|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3
119 +---+ | | / | Link +----|--|----+ Link | \ | | +--+
120 +-----------+ | | +----------+
121 +--+ +--+
122 | |
123 Rs v | Ss
124 +-----+ +-----+
125 |RxLx | |TxLx |
126 +-----+ +-----+
128 Ss = Sender reference point at the DWDM network element
129 tributary output
130 Rs = Receiver reference point at the DWDM network element
131 tributary input
132 Lx = Lambda x
133 OM = Optical Mux
134 OD = Optical Demux
135 ROADM = Reconfigurable Optical Add Drop Mux
137 from Fig. 5.1/G.698.2
139 Figure 1: Linear Single Channel approach
141 Figure 2 Extended LMP Model ( from [RFC4209] )
143 +------+ Ss +------+ +------+ Rs +------+
144 | | ----- | | | | ----- | |
145 | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
146 | | ----- | | | | ----- | |
147 +------+ +------+ +------+ +------+
148 ^ ^ ^ ^ ^ ^
149 | | | | | |
150 | +-----LMP-----+ +-----LMP-----+ |
151 | |
152 +----------------------LMP-----------------------+
154 OXC : is an entity that contains transponders
155 OLS : generic optical system, it can be -
156 Optical Mux, Optical Demux, Optical Add
157 Drop Mux, Amplifier etc.
158 OLS to OLS : represents the Optical Multiplex section
159
160 Rs/Ss : reference points in between the OXC and the OLS
162 Figure 2: Extended LMP Model
164 3. Use Cases
166 A comparison with the traditional operation scenarios provides an
167 insight of similarities and distinctions in operation and management
168 of DWDM interfaces. The following use cases provide an overview
169 about operation and maintenance processes.
171 3.1. Optical interface parameter collection
173 It is necessary to identify the Optical interface characteristics and
174 setting in order to properly calculate the ent to end path and match
175 the Head End interface against the Tail End interface compatibility.
176 The optical parameters may have multiple possible values that the
177 Controller (SDN or GMPLS) can use and select for the best network
178 optimisation. In case og GMPLS the LMP is suitable to support the
179 parameters exchange between the ROADM and the Transponder (or DWDM
180 interface located into the client box).
182 3.2. DWDM client - ROADM interconection discovery
184 Being the DWDM port (Rs and Ss) and ROADM port belonging to different
185 domains and Network Elements, the interconnection between them is not
186 embedded in the Optical Nodes (OLS layer) and can not be shared to
187 the EMS and the Controller. The Controller needs then to retrieve
188 the connectivity using data coming from the two domains correlating
189 them to discover the relationship. The methods to discover the
190 interconnection can be LMP, LLDP, installation provisioning or any
191 other mechanism using the light (or power) transmitted by the DWDM
192 transmitter and detecter by the ROAMD port photodiode. This use case
193 is fundamental to build the interconnections between the DWDM and
194 Client layer (e.g. Routers) and re-build the multilayer network
195 topology.
197 3.3. Service Setup
199 It is necessary to differentiate between different operational issues
200 for setting up a light path (a DWDM connection is specific in having
201 defined maximum impairments) within an operational network.
203 The first step is to determine if transceivers located at different
204 end-points are interoperable, i.e. support a common set of
205 operational parameters. In this step it is required to determine
206 transceiver capabilities in a way to be able to correlate them for
207 interoperability purposes. Such parameters include modulation
208 scheme, modulation parameters, FEC to name a few. If both
209 transceivers are controlled by the same NMS or Control Plane, such
210 data is readily available. However in cases where the transceivers
211 are controlled by different CP, a protocol needs to be used to inform
212 the controlling instance (NMS or CP) about transceiver parameters.
213 It is suggested to extend LMP for that purpose.
215 The second step is to determine the feasibility of a lightpath
216 between two transceivers without applying an optical signal.
217 Understanding the limitations of the transceiver pair, a path through
218 the optical network has to be found, whereby each path has an
219 individual set of impairments deteriorating a wavelength traveling
220 along that path. Since a single transceiver can support multiple
221 parameter sets, the selection of a path may limit the permissible
222 parameter sets determined in previous steps.
224 The third step is then to setup the connection itself and to
225 determine the Wavelength. This is done using the NMS of the optical
226 transport network or by means of a control plane interaction such as
227 signaling and includes the path information as well as the parameter
228 set information necessary to enable communication.
230 In a fourth step, optical monitoring is activated in the WDM network
231 in order to monitor the status of the connection. The monitor
232 functions of the optical interfaces at the terminals are also
233 activated in order to monitor the end to end connection.
235 Furthermore it should be possible to automate this step. After
236 connecting the client device to the neighbor control plane-enabled
237 transport node, a control adjacency may be automatically established,
238 e.g. using LMP.
240 3.4. Link Monitoring Use Cases
242 The use cases described below are assuming that power monitoring
243 functions are available in the ingress and egress network element of
244 the DWDM network, respectively. By performing link property
245 correlation it would be beneficial to include the current transmit
246 power value at reference point Ss and the current received power
247 value at reference point Rs. For example if the Client transmitter
248 power has a value of 0dBm and the ROADM interface measured power is
249 -6dBm the fiber patch cord connecting the two nodes may be pinched or
250 the connectors are dirty. As discussed before, the actual path or
251 selection of a specific wavelength within the allowed set is outside
252 the scope of LMP. The computing entities (e.g. the first optical
253 node originating the circuit) can rely on GMPLS IGP (OSPF) to
254 retrieve all the information related to the network, calculate the
255 path to reach the endpoint and signal the path implementation through
256 the network via RSVP-TE.
258 [ITU-T.G.698.2] defines a single channel optical interface for DWDM
259 systems that allows interconnecting network-external optical
260 transponders across a DWDM network. The optical transponders are
261 external to the DWDM network. This so-called 'Black Link' approach
262 illustrated in Fig. 5-1 of [ITU-T.G.698.2]. The single channel fiber
263 link between the Ss/Rs reference points and the ingress/egress port
264 of the network element on the domain boundary of the DWDM network
265 (DWDM border NE) is called access link. Based on the definition in
266 [ITU-T.G.698.2] it is part of the DWDM network. The access link is
267 typically realized as a passive fiber link that has a specific
268 optical attenuation (insertion loss). As the access link is an
269 integral part of the DWDM network, it is desirable to monitor its
270 attenuation. Therefore, it is useful to detect an increase of the
271 access link attenuation, for example, when the access link fiber has
272 been disconnected and reconnected (maintenance) and a bad patch panel
273 connection (connector) resulted in a significantly higher access link
274 attenuation (loss of signal in the extreme case of an open connector
275 or a fiber cut). In the following section, two use cases are
276 presented and discussed:
278 1) pure access link monitoring
279 2) access link monitoring with a power control loop
281 These use cases require a power monitor as described in G.697 (see
282 section 6.1.2), that is capable to measure the optical power of the
283 incoming or outgoing single channel signal. The use case where a
284 power control loop is in place could even be used to compensate an
285 increased attenuation if the optical transmitter can still be
286 operated within its output power range defined by its application
287 code.
289 4. Extensions to LMP-WDM Protocol
291 This document defines extensions to [RFC4209] to allow a set of
292 characteristic parameters, to be exchanged between a router or
293 optical switch (e.g. OTN cross connect) and the optical line system
294 to which it is attached. In particular, this document defines
295 additional Data Link sub-objects to be carried in the LinkSummary
296 message defined in [RFC4204] and [RFC6205]. The OXC and OLS systems
297 may be managed by different Network management systems and hence may
298 not know the capability and status of their peer. These messages and
299 their usage are defined in subsequent sections of this document.
301 The following new messages are defined for the WDM extension for
302 ITU-T G.698.2 [ITU-T.G698.2]/ITU-T G.698.1 [ITU-T.G698.1]/
303 ITU-T G.959.1 [ITU-T.G959.1]
304 - OCh_General (sub-object Type = TBA)
305 - OCh_ApplicationIdentier (sub-object Type = TBA)
306 - OCh_Ss (sub-object Type = TBA)
307 - OCh_Rs (sub-object Type = TBA)
309 5. General Parameters - OCh_General
311 These are a set of general parameters as described in [G698.2] and
312 [G.694.1]. Please refer to the "draft-ietf-ccamp-dwdm-if-param-yang"
313 for more details about these parameters and the [RFC6205] for the
314 wavelength definition.
316 The general parameters are
317 1. Central Frequency - (Tera Hz) 4 bytes (see RFC6205 sec.3.2)
318 2. Number of Application Identifiers (A.I.) Supported
319 3. Single-channel Application Identifier in use
320 4. Application Identifier Type in use
321 5. Application Identifier in use
323 Figure 3: The format of the this sub-object (Type = TBA, Length =
324 TBA) is as follows:
326 0 1 2 3
327 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
328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
329 | Type | Length | (Reserved) |
330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
331 | Central Frequency |
332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
333 | Number of Application | |
334 | Identifiers Supported | (Reserved) |
335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
336 | Single-channel| A.I. Type | A.I. length |
337 | Application | in use | |
338 | Identifier | | |
339 | Number in use | | |
340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
341 | Single-channel Application Identifier in use |
342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
343 | Single-channel Application Identifier in use |
344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
345 | Single-channel Application Identifier in use |
346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
348 A.I. Type in use: STANDARD, PROPRIETARY
350 A.I. Type in use: STANDARD
352 Refers to G.698.2 recommendation (e.g.) : B-DScW-ytz(v)
354 0 1 2 3
355 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
356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
357 | Single-channel Application Code |
358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
359 | Single-channel Application Code |
360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
361 | Single-channel Application Code |
362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
364 A.I. Type in use: PROPRIETARY
366 Note: if the A.I. type = PROPRIETARY, the first 6 Octets of the
367 Application Identifier in use are six characters of the
368 PrintableString must contain the Hexadecimal representation of
369 an OUI (Organizationally Unique Identifier) assigned to the
370 vendor whose implementation generated the Application
371 Identifier; the remaining octets of the PrintableString are
372 unspecified.
374 0 1 2 3
375 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
376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
377 | OUI |
378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
379 | OUI cont. | Vendor value |
380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
381 | Vendor Value |
382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
384 Figure 3: OCh_General
386 6. ApplicationIdentifier - OCh_ApplicationIdentifier
388 This message is to exchange the application identifiers supported as
389 described in [G698.2]. There can be more than one Application
390 Identifier supported by the transmitter/receiver in the OXC. The
391 number of application identifiers supported is exchanged in the
392 "OCh_General" message. (from [G698.1]/[G698.2]/[G959.1] and G.874.1)
394 The parameters are:
396 1. Number of Application Identifiers (A.I.) Supported
398 2. Single-channel application identifier Number
399 uniquely identifiers this entry - 8 bits
401 3. Application Indentifier Type (A.I.) (STANDARD/PROPRIETARY)
403 4. Single-channel application identifier -- 96 bits
404 (from [G698.1]/[G698.2]/[G959.1]
406 - this parameter can have
407 multiple instances as the transceiver can support multiple
408 application identifiers.
410 Figure 4: The format of the this sub-object (Type = TBA, Length =
411 TBA) is as follows:
413 0 1 2 3
414 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
415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
416 | Type | Length | (Reserved) |
417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
418 | Number of Application | |
419 | Identifiers Supported | (Reserved) |
420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
421 | Single-channel| A.I. Type | A.I. length |
422 | Application | | |
423 | Identifier | | |
424 | Number | | |
425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
426 | Single-channel Application Identifier |
427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
428 | Single-channel Application Identifier |
429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
430 | Single-channel Application Identifier |
431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
432 // .... //
433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
434 | Single-channel| | A.I. length |
435 | Application | A.I. Type | |
436 | Identifier | | |
437 | Number | | |
438 | | | |
439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
440 | Single-channel Application Identifier |
441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
442 | Single-channel Application Identifier |
443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
444 | Single-channel Application Identifier |
445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
447 A.I. Type in use: STANDARD, PROPRIETARY
449 A.I. Type in use: STANDARD
450 Refers to G.698.2 recommendation : B-DScW-ytz(v)
452 0 1 2 3
453 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
454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
455 | Single-channel Application Code |
456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
457 | Single-channel Application Code |
458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
459 | Single-channel Application Code |
460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
461 A.I. Type in use: PROPRIETARY
463 Note: if the A.I. type = PROPRIETARY, the first 6 Octets of the
464 Application Identifier in use are six characters of the
465 PrintableString must contain the Hexadecimal representation of
466 an OUI (Organizationally Unique Identifier) assigned to the
467 vendor whose implementation generated the Application
468 Identifier; the remaining octets of the PrintableString are
469 unspecified.
471 0 1 2 3
472 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
473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
474 | OUI |
475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
476 | OUI cont. | Vendor value |
477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
478 | Vendor Value |
479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
481 Figure 4: OCh_ApplicationIdentifier
483 7. OCh_Ss - OCh transmit parameters
485 These are the G.698.2 parameters at the Source(Ss reference points).
486 Please refer to "draft-ietf-ccamp-dwdm-if-param-yang" for more
487 details about these parameters.
489 1. Output power
491 Figure 5: The format of the OCh sub-object (Type = TBA, Length = TBA)
492 is as follows:
494 0 1 2 3
495 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
496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
497 | Type | Length | (Reserved) |
498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
499 | Output Power |
500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
502 Figure 5: OCh_Ss transmit parameters
504 8. OCh_Rs - receive parameters
506 These are the G.698.2 parameters at the Sink (Rs reference points).
508 1. Current Input Power - (0.1dbm) 4bytes
510 Figure 6: The format of the OCh receive sub-object (Type = TBA,
511 Length = TBA) is as follows:
513 The format of the OCh receive/OLS Sink sub-object (Type = TBA,
514 Length = TBA) is as follows:
516 0 1 2 3
517 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
518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
519 | Type | Length | (Reserved) |
520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
521 | Current Input Power |
522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
524 Figure 6: OCh_Rs receive parameters
526 9. Security Considerations
528 LMP message security uses IPsec, as described in [RFC4204]. This
529 document only defines new LMP objects that are carried in existing
530 LMP messages, similar to the LMP objects in [RFC:4209]. This
531 document does not introduce new security considerations.
533 10. IANA Considerations
534 LMP defines the following name spaces and
535 the ways in which IANA can make assignments to these namespaces:
537 - LMP Message Type
538 - LMP Object Class
539 - LMP Object Class type (C-Type) unique within the Object Class
540 - LMP Sub-object Class type (Type) unique within the Object Class
541 This memo introduces the following new assignments:
543 LMP Sub-Object Class names:
545 under DATA_LINK Class name (as defined in )
546 - OCh_General (sub-object Type = TBA)
547 - OCh_ApplicationIdentifier (sub-object Type = TBA)
548 - OCh_Ss (sub-object Type = TBA)
549 - OCh_Rs (sub-object Type = TBA)
551 11. Contributors
553 Arnold Mattheus
554 Deutsche Telekom
555 Darmstadt
556 Germany
557 email a.mattheus@telekom.de
559 John E. Drake
560 Juniper
561 1194 N Mathilda Avenue
562 HW-US,Pennsylvania
563 USA
564 jdrake@juniper.net
566 Zafar Ali
567 Cisco
568 3000 Innovation Drive
569 KANATA
570 ONTARIO K2K 3E8
571 zali@cisco.com
573 12. References
574 12.1. Normative References
576 [ITU-T.G.698.2]
577 International Telecommunications Union, "Amplified
578 multichannel dense wavelength division multiplexing
579 applications with single channel optical interfaces",
580 ITU-T Recommendation G.698.2, November 2009.
582 [ITU-T.G694.1]
583 International Telecommunications Union, ""Spectral grids
584 for WDM applications: DWDM frequency grid"",
585 ITU-T Recommendation G.698.2, February 2012.
587 [ITU-T.G709]
588 International Telecommunications Union, "Interface for the
589 Optical Transport Network (OTN)", ITU-T Recommendation
590 G.709, June 2016.
592 [ITU-T.G872]
593 International Telecommunications Union, "Architecture of
594 optical transport networks", ITU-T Recommendation G.872,
595 January 2017.
597 [ITU-T.G874.1]
598 International Telecommunications Union, "Optical transport
599 network (OTN): Protocol-neutral management information
600 model for the network element view", ITU-T Recommendation
601 G.874.1, November 2016.
603 [RFC4054] Strand, J., Ed. and A. Chiu, Ed., "Impairments and Other
604 Constraints on Optical Layer Routing", RFC 4054,
605 DOI 10.17487/RFC4054, May 2005,
606 .
608 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
609 DOI 10.17487/RFC4204, October 2005,
610 .
612 [RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management
613 Protocol (LMP) for Dense Wavelength Division Multiplexing
614 (DWDM) Optical Line Systems", RFC 4209,
615 DOI 10.17487/RFC4209, October 2005,
616 .
618 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for
619 Lambda-Switch-Capable (LSC) Label Switching Routers",
620 RFC 6205, DOI 10.17487/RFC6205, March 2011,
621 .
623 12.2. Informative References
625 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
626 DOI 10.17487/RFC2629, June 1999,
627 .
629 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
630 "Introduction and Applicability Statements for Internet-
631 Standard Management Framework", RFC 3410,
632 DOI 10.17487/RFC3410, December 2002,
633 .
635 [RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of
636 MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181,
637 September 2005, .
639 Authors' Addresses
641 Dharini Hiremagalur (editor)
642 Juniper
643 1194 N Mathilda Avenue
644 Sunnyvale - 94089 California
645 USA
647 Phone: +1408
648 Email: dharinih@juniper.net
650 Gert Grammel (editor)
651 Juniper
652 Oskar-Schlemmer Str. 15
653 80807 Muenchen
654 Germany
656 Phone: +49 1725186386
657 Email: ggrammel@juniper.net
659 Gabriele Galimberti (editor)
660 Cisco
661 Via S. Maria Molgora, 48 c
662 20871 - Vimercate
663 Italy
665 Phone: +390392091462
666 Email: ggalimbe@cisco.com
667 Ruediger Kunze (editor)
668 Deutsche Telekom
669 Winterfeldtstr. 21-27
670 10781 Berlin
671 Germany
673 Phone: +491702275321
674 Email: RKunze@telekom.de
676 Dieter Beller
677 Nokia
678 Lorenzstrasse, 10
679 70435 Stuttgart
680 Germany
682 Phone: +4971182143125
683 Email: Dieter.Beller@nokia.com