idnits 2.17.1
draft-dharinigert-ccamp-g-698-2-lmp-10.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 ([ITU.G698.2], [ITU.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 (July 6, 2015) is 3210 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.G959.1' is mentioned on line 426, but not defined
== Missing Reference: 'G.694.1' is mentioned on line 435, but not defined
== Unused Reference: 'RFC4054' is defined on line 709, but no explicit
reference was found in the text
== Unused Reference: 'ITU.G709' is defined on line 723, but no explicit
reference was found in the text
== Unused Reference: 'ITU.G872' is defined on line 728, but no explicit
reference was found in the text
== Unused Reference: 'ITU.G874.1' is defined on line 733, but no explicit
reference was found in the text
== Unused Reference: 'RFC3410' is defined on line 741, but no explicit
reference was found in the text
== Unused Reference: 'RFC2629' is defined on line 745, but no explicit
reference was found in the text
== Unused Reference: 'RFC4181' is defined on line 748, but no explicit
reference was found in the text
== Unused Reference: 'I-D.kunze-g-698-2-management-control-framework' is
defined on line 751, but no explicit reference was found in the text
** Downref: Normative reference to an Informational RFC: RFC 4054
-- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G698.2'
-- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G694.1'
-- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G709'
-- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G872'
-- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G874.1'
-- Obsolete informational reference (is this intentional?): RFC 2629
(Obsoleted by RFC 7749)
== Outdated reference: A later version (-02) exists of
draft-kunze-g-698-2-management-control-framework-00
Summary: 2 errors (**), 0 flaws (~~), 12 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: January 7, 2016 G. Galimberti, Ed.
6 Z. Ali, Ed.
7 Cisco
8 R. Kunze, Ed.
9 Deutsche Telekom
10 D. Beller, Ed.
11 ALU
12 July 6, 2015
14 Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense
15 Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage
16 the application code of optical interface parameters in DWDM application
17 draft-dharinigert-ccamp-g-698-2-lmp-10
19 Abstract
21 This memo defines extensions to LMP(rfc4209) for managing Optical
22 parameters associated with Wavelength Division Multiplexing (WDM)
23 systems or characterized by the Optical Transport Network (OTN) in
24 accordance with the Interface Application Code approach defined in
25 ITU-T Recommendation G.698.2.[ITU.G698.2], G.694.1.[ITU.G694.1] and
26 its extensions.
28 Copyright Notice
30 Copyright (c) 2011 IETF Trust and the persons identified as the
31 document authors. All rights reserved.
33 Status of This Memo
35 This Internet-Draft is submitted in full conformance with the
36 provisions of BCP 78 and BCP 79.
38 Internet-Drafts are working documents of the Internet Engineering
39 Task Force (IETF). Note that other groups may also distribute
40 working documents as Internet-Drafts. The list of current Internet-
41 Drafts is at http://datatracker.ietf.org/drafts/current/.
43 Internet-Drafts are draft documents valid for a maximum of six months
44 and may be updated, replaced, or obsoleted by other documents at any
45 time. It is inappropriate to use Internet-Drafts as reference
46 material or to cite them other than as "work in progress."
48 This Internet-Draft will expire on January 7, 2016.
50 Copyright Notice
52 Copyright (c) 2015 IETF Trust and the persons identified as the
53 document authors. All rights reserved.
55 This document is subject to BCP 78 and the IETF Trust's Legal
56 Provisions Relating to IETF Documents
57 (http://trustee.ietf.org/license-info) in effect on the date of
58 publication of this document. Please review these documents
59 carefully, as they describe your rights and restrictions with respect
60 to this document. Code Components extracted from this document must
61 include Simplified BSD License text as described in Section 4.e of
62 the Trust Legal Provisions and are provided without warranty as
63 described in the Simplified BSD License.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
68 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
69 3. Extensions to LMP-WDM Protocol . . . . . . . . . . . . . . . 11
70 4. General Parameters - OCh_General . . . . . . . . . . . . . . 11
71 5. ApplicationIdentifier - OCh_ApplicationIdentifier . . . . . . 13
72 6. OCh_Ss - OCh transmit parameters . . . . . . . . . . . . . . 15
73 7. OCh_Rs - receive parameters . . . . . . . . . . . . . . . . . 15
74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
76 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
78 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
79 11.2. Informative References . . . . . . . . . . . . . . . . . 18
80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
82 1. Introduction
84 This extension is based on "draft-galikunze-ccamp-g-698-2-snmp-mib-
85 10", for the relevant interface optical parameters described in
86 recommendations like ITU-T G.698.2 [ITU.G698.2] and
87 G.694.1.[ITU.G694.1]. The LMP Model from RFC4902 provides link
88 property correlation between a client and an OLS device. LMP link
89 property correlation, exchanges the capabilities of either end of the
90 link where the term 'link' refers to the attachment link between OXC
91 and OLS (see Figure 1). By performing link property correlation,
92 both ends of the link exchange link properties, such as application
93 identifiers. This allows either end to operate within a commonly
94 understood parameter window. Based on known parameter limits, each
95 device can supervise the received signal for conformance using
96 mechanisms defined in RFC3591. For example if the Client transmitter
97 power (OXC1) has a value of 0dBm and the ROADM interface measured
98 power (at OLS1) is -6dBm the fiber patch cord connecting the two
99 nodes may be pinched or the connectors are dirty. More, the
100 interface characteristics can be used by the OLS network Control
101 Plane in order to check the Optical Channels feasibility. Finally
102 the OXC1 transceivers parameters (Application Code) can be shared
103 with OXC2 using the LMP protocol to verify the Transceivers
104 compatibility. The actual route selection of a specific wavelength
105 within the allowed set is outside the scope of LMP. In GMPLS, the
106 parameter selection (e.g. central frequency) is performed by RSVP-TE.
108 Figure 1 shows a set of reference points, for the linear "black link"
109 approach, for single-channel connection (Ss and Rs) between
110 transmitters (Tx) and receivers (Rx). Here the DWDM network elements
111 include an OM and an OD (which are used as a pair with the opposing
112 element), one or more optical amplifiers and may also include one or
113 more OADMs.
115 +-------------------------------------------------+
116 Ss | DWDM Network Elements | Rs
117 +--+ | | | \ / | | | +--+
118 Tx L1--|->| \ +------+ +------+ / |--|-->Rx L1
119 +---+ | | | | | +------+ | | | | | +--+
120 +---+ | | | | | | | | | | | | +--+
121 Tx L2--|->| OM |-->|------|->| OADM |--|------|->| OD |--|-->Rx L2
122 +---+ | | | | | | | | | | | | +--+
123 +---+ | | | | | +------+ | | | | | +--+
124 Tx L3--|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3
125 +---+ | | / | Link +----|--|----+ Link | \ | | +--+
126 +-----------+ | | +----------+
127 +--+ +--+
128 | |
129 Rs v | Ss
130 +-----+ +-----+
131 |RxLx | |TxLx |
132 +-----+ +-----+
133 Ss = reference point at the DWDM network element tributary output
134 Rs = reference point at the DWDM network element tributary input
135 Lx = Lambda x
136 OM = Optical Mux
137 OD = Optical Demux
138 OADM = Optical Add Drop Mux
140 from Fig. 5.1/G.698.2
142 Figure 1: Linear Black Link approach
144 Figure 2 Extended LMP Model ( from [RFC4209] )
146 +------+ Ss +------+ +------+ Rs +------+
147 | | ----- | | | | ----- | |
148 | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
149 | | ----- | | | | ----- | |
150 +------+ +------+ +------+ +------+
151 ^ ^ ^ ^ ^ ^
152 | | | | | |
153 | +-----LMP-----+ +-----LMP-----+ |
154 | |
155 +----------------------LMP-----------------------+
157 OXC : is an entity that contains transponders
158 OLS : generic optical system, it can be -
159 Optical Mux, Optical Demux, Optical Add
160 Drop Mux, etc.
161 OLS to OLS : represents the black-Link itself
162 Rs/Ss : in between the OXC and the OLS
164 Figure 2: Extended LMP Model
166 2. Use Cases
168 The use cases described below are assuming that power monitoring
169 functions are available in the ingress and egress network element of
170 the DWDM network, respectively. By performing link property
171 correlation it would be beneficial to include the current transmit
172 power value at reference point Ss and the current received power
173 value at reference point Rs. For example if the Client transmitter
174 power (OXC1) has a value of 0dBm and the ROADM interface measured
175 power (at OLS1) is -6dBm the fiber patch cord connecting the two
176 nodes may be pinched or the connectors are dirty. More, the
177 interface characteristics can be used by the OLS network Control
178 Plane in order to check the Optical Channels feasibility. Finally
179 the OXC1 transceivers parameters (Application Code) can be shared
180 with OXC2 using the LMP protocol to verify the Transceivers
181 compatibility. The actual route selection of a specific wavelength
182 within the allowed set is outside the scope of LMP. In GMPLS, the
183 parameter selection (e.g. central frequency) is performed by RSVP-TE.
185 G.698.2 defines a single channel optical interface for DWDM systems
186 that allows interconnecting network-external optical transponders
187 across a DWDM network. The optical transponders are considered to be
188 external to the DWDM network. This so-called 'black link' approach
189 illustrated in Figure 5-1 of G.698.2 and a copy of this figure is
190 provided below. The single channel fiber link between the Ss/Rs
191 reference points and the ingress/egress port of the network element
192 on the domain boundary of the DWDM network (DWDM border NE) is called
193 access link in this contribution. Based on the definition in G.698.2
194 it is considered to be part of the DWDM network. The access link
195 typically is realized as a passive fiber link that has a specific
196 optical attenuation (insertion loss). As the access link is an
197 integral part of the DWDM network, it is desirable to monitor its
198 attenuation. Therefore, it is useful to detect an increase of the
199 access link attenuation, for example, when the access link fiber has
200 been disconnected and reconnected (maintenance) and a bad patch panel
201 connection (connector) resulted in a significantly higher access link
202 attenuation (loss of signal in the extreme case of an open connector
203 or a fiber cut). In the following section, two use cases are
204 presented and discussed:
206 1) pure access link monitoring
207 2) access link monitoring with a power control loop
209 These use cases require a power monitor as described in G.697 (see
210 section 6.1.2), that is capable to measure the optical power of the
211 incoming or outgoing single channel signal. The use case where a
212 power control loop is in place could even be used to compensate an
213 increased attenuation as long as the optical transmitter can still be
214 operated within its output power range defined by its application
215 code.
217 Figure 3 Access Link Power Monitoring
219 +--------------------------+
220 | P(in) = P(Tx) - a(Tx) |
221 | ___ |
222 +----------+ | \ / Power Monitor |
223 | | P(Tx) | V P(in) |
224 | +----+ | Ss //\\ | | |\ |
225 | | TX |----|-----\\//------------------->| \ |
226 | +----+ | Access Link (AL-T) | . | | |
227 | | attenuation a(Tx) | . | |==============>
228 | | | . | | |
229 | External | | --->| / |
230 | Optical | | |/ |
231 |Transpond.| | P(out) |
232 | | | ___ |
233 | | | \ / Power Monitor |
234 | | P(Rx) | V P(out) |
235 | +----+ | Rs //\\ | | |\ |
236 | | RX |<---|-----\\//--------------------| \ |
237 | +----+ | Access Link (AL-R) | . | | |
238 | | Attenuation a(Rx) | . | |<==============
239 +----------+ | . | | |
240 | <---| / |
241 P(Rx) = P(out) - a(Rx) | |/ |
242 | |
243 | ROADM |
244 +--------------------------+
246 - For AL-T monitoring: P(Tx) and a(Tx) must be known
247 - For AL-R monitoring: P(RX) and a(Rx) must be known
249 An alarm shall be raised if P(in) or P(Rx) drops below a
250 configured threshold (t [dB]):
251 - P(in) < P(Tx) - a(Tx) - t (Tx direction)
252 - P(Rx) < P(out) - a(Rx) - t (Rx direction)
253 - a(Tx) =| a(Rx)
255 Figure 3: Extended LMP Model
257 Pure Access Link (AL) Monitoring Use Case
259 Figure 4 illustrates the access link monitoring use case and the
260 different physical properties involved that are defined below:
262 - Ss, Rs: G.698.2 reference points
263 - P(Tx): current optical output power of transmitter Tx
264 - a(Tx): access link attenuation in Tx direction (external
265 transponder point of view)
266 - P(in): measured current optical input power at the input port
267 of border DWDM NE
268 - t: user defined threshold (tolerance)
269 - P(out): measured current optical output power at the output port
270 of border DWDM NE
271 - a(Rx): access link attenuation in Rx direction (external
272 transponder point of view)
273 - P(Rx): current optical input power of receiver Rx
275 Assumptions:
276 - The access link attenuation in both directions (a(Tx), a(Rx))
277 is known or can be determined as part of the commissioning
278 process. Typically, both values are the same.
279 - A threshold value t has been configured by the operator. This
280 should also be done during commissioning.
281 - A control plane protocol (e.g. this draft) is in place that allows
282 to periodically send the optical power values P(Tx) and P(Rx)
283 to the control plane protocol instance on the DWDM border NE.
284 This is llustrated in Figure 3.
285 - The DWDM border NE is capable to periodically measure the optical
286 power Pin and Pout as defined in G.697 by power monitoring points
287 depicted as yellow triangles in the figures below.
289 AL monitoring process:
290 - Tx direction: the measured optical input power Pin is compared
291 with the expected optical input power P(Tx) - a(Tx). If the
292 measured optical input power P(in) drops below the value
293 (P(Tx) - a(Tx) - t) a low power alarm shall be raised indicating
294 that the access link attenuation has exceeded a(Tx) + t.
295 - Rx direction: the measured optical input power P(Rx) is
296 compared with the expected optical input power P(out) - a(Rx).
297 If the measured optical input power P(Rx) drops below the value
298 (P(out) - a(Rx) - t) a
299 low power alarm shall be raised indicating that the access link
300 attenuation has exceeded a(Rx) + t.
302 Figure 4 Use case 1: Access Link power monitoring
304 +----------+ +--------------------------+
305 | +------+ | P(Tx), P(Rx) | +-------+ |
306 | | | | =================> | | | |
307 | | LMP | | P(in), P(out) | | LMP | |
308 | | | | <================= | | | |
309 | +------+ | | +-------+ |
310 | | | |
311 | | | P(in) - P(Tx) - a(Tx) |
312 | | | ___ |
313 | | | \ / Power Monitor |
314 | | P(Tx) | V |
315 | +----+ | Ss //\\ | | |\ |
316 | | TX |----|-----\\//------------------->| \ |
317 | +----+ | Access Link (AL-T) | . | | |
318 | | attenuation a(Tx) | . | |==============>
319 | | | . | | |
320 | External | | --->| / |
321 | Optical | | |/ |
322 |Transpond.| | P(out) |
323 | | | ___ |
324 | | | \ / Power Monitor |
325 | | P(Rx) | V |
326 | +----+ | Rs //\\ | | |\ |
327 | | RX |<---|-----\\//--------------------| \ |
328 | +----+ | Access Link (AL-R) | . | | |
329 | | Attenuation a(Rx) | . | |<==============
330 +----------+ | . | | |
331 | <---| / |
332 P(Rx) = P(out) - a(Rx) | |/ |
333 | |
334 | ROADM |
335 +--------------------------+
337 - For AL-T monitoring: P(Tx) and a(Tx) must be known
338 - For AL-R monitoring: P(RX) and a(Rx) must be known
339 An alarm shall be raised if P(in) or P(Rx) drops below a
340 configured threshold (t [dB]):
341 - P(in) < P(Tx) - a(Tx) - t (Tx direction)
342 - P(Rx) < P(out) - a(Rx) - t (Rx direction)
343 - a(Tx) = a(Rx)
345 Figure 4: Extended LMP Model
347 Power Control Loop Use Case
349 This use case is based on the access link monitoring use case as
350 described above. In addition, the border NE is running a power
351 control application that is capable to control the optical output
352 power of the single channel tributary signal at the output port
353 of the border DWDM NE (towards the external receiver Rx) and the
354 optical output power of the single channel tributary signal at
355 the external transmitter Tx within their known operating range.
356 The time scale of this control loop is typically relatively slow
357 (e.g. some 10s or minutes) because the access link attenuation
358 is not expected to vary much over time (the attenuation only
359 changes when re-cabling occurs).
360 From a data plane perspective, this use case does not require
361 additional data plane extensions. It does only require a protocol
362 extension in the control plane (e.g. this LMP draft) that allows
363 the power control application residing in the DWDM border NE to
364 modify the optical output power of the DWDM domain-external
365 transmitter Tx within the range of the currently used application
366 code. Figure 5 below illustrates this use case utilizing the LMP
367 protocol with extensions defined in this draft.
369 Figure 5 Use case 2: Power Control Loop
371 +----------+ +--------------------------+
372 | +------+ | P(Tx),P(Rx),Set(Pout) | +-------+ +--------+ |
373 | | | | ====================> | | | | Power | |
374 | | LMP | | P(in),P(out),Set(PTx) | | LMP | |Control | |
375 | | | | <==================== | | | | Loop | |
376 | +------+ | | +-------+ +--------+ |
377 | | | | |
378 | +------+ | | P(in) = P(Tx) - a(Tx) |
379 | |C.Loop| | | ___ |
380 | +------+ | | \ / Power Monitor |
381 | | | P(Tx) | V |
382 | +------+ | Ss //\\ | | |\ |
383 | | TX |>----|-----\\//---------------------->| \ |
384 | +------+ | Access Link (AL-T) | . | | |
385 | VOA(Tx) | attenuation a(Tx) | . | |==============>
386 | | | . | | |
387 | External | | --->| / |
388 | Optical | | |/ |
389 |Transpond.| | P(out) |
390 | | | ___ |
391 | | | \ / Power Monitor |
392 | | P(Rx) | V |
393 | +----+ | Rs //\\ | | VOA(out) |\ |
394 | | RX |<---|-----\\//---------------------<|-------| \ |
395 | +----+ | Access Link (AL-R) | . | | |
396 | | attenuation a(Rx) | . | |<=======
397 +----------+ | VOA(out) | | |
398 | <--<|-------| / |
399 P(Rx) = P(out) - a(Rx) | |/ |
400 | |
401 | ROADM |
402 +--------------------------+
404 - The Power Control Loops in Transponder and ROADM regulate
405 the Variable Optical Attenuators (VOA) to adjust the proper
406 power in base of the ROADM and Receiver caracteristics and
407 the Access Link attenuation
409 Figure 5: Extended LMP Model
411 3. Extensions to LMP-WDM Protocol
413 This document defines extensions to [RFC4209] to allow the Black Link
414 (BL) parameters of G.698.2, to be exchanged between a router or
415 optical switch and the optical line system to which it is attached.
416 In particular, this document defines additional Data Link sub-objects
417 to be carried in the LinkSummary message defined in [RFC4204] and
418 [RFC6205]. The OXC and OLS systems may be managed by different
419 Network management systems and hence may not know the capability and
420 status of their peer. The intent of this draft is to enable the OXC
421 and OLS systems to exchange this information. These messages and
422 their usage are defined in subsequent sections of this document.
424 The following new messages are defined for the WDM extension for
425 ITU-T G.698.2 [ITU.G698.2]/ITU-T G.698.1 [ITU.G698.1]/
426 ITU-T G.959.1 [ITU.G959.1]
427 - OCh_General (sub-object Type = TBA)
428 - OCh_ApplicationIdentier (sub-object Type = TBA)
429 - OCh_Ss (sub-object Type = TBA)
430 - OCh_Rs (sub-object Type = TBA)
432 4. General Parameters - OCh_General
434 These are the general parameters as described in [G698.2] and
435 [G.694.1]. Please refer to the "draft-galikunze-ccamp-g-698-2-snmp-
436 mib-12" for more details about these parameters and the [RFC6205] for
437 the wavelength definition.
439 The general parameters are
440 1. Central Frequency - (Tera Hz) 4 bytes (see RFC6205 sec.3.2)
441 2. Number of Application Identifiers (A.I.) Supported
442 3. Single-channel Application Identifier in use
443 4. Application Identifier Type in use
444 5. Application Identifier in use
446 Figure 6: The format of the this sub-object (Type = TBA, Length =
447 TBA) is as follows:
449 0 1 2 3
450 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
451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
452 | Type | Length | (Reserved) |
453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
454 | Central Frequency |
455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
456 | Number of Application | |
457 | Identifiers Supported | (Reserved) |
458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
459 | Single-channel| A.I. Type | A.I. length |
460 | Application | in use | |
461 | Identifier | | |
462 | Number in use | | |
463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
464 | Single-channel Application Identifier in use |
465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
466 | Single-channel Application Identifier in use |
467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
468 | Single-channel Application Identifier in use |
469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
471 A.I. Type in use: STANDARD, PROPRIETARY
473 A.I. Type in use: STANDARD
475 Refer to G.698.2 recommendation : B-DScW-ytz(v)
477 0 1 2 3
478 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
479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
480 | Single-channel Application Code |
481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
482 | Single-channel Application Code |
483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
484 | Single-channel Application Code |
485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
487 A.I. Type in use: PROPRIETARY
489 Note: if the A.I. type = PROPRIETARY, the first 6 Octets of the
490 Application Identifier in use are six characters of the
491 PrintableString must contain the Hexadecimal representation of
492 an OUI (Organizationally Unique Identifier) assigned to the
493 vendor whose implementation generated the Application
494 Identifier; the remaining octets of the PrintableString are
495 unspecified.
497 0 1 2 3
498 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
499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
500 | OUI |
501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
502 | OUI cont. | Vendor value |
503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
504 | Vendor Value |
505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
507 Figure 6: OCh_General
509 5. ApplicationIdentifier - OCh_ApplicationIdentifier
511 This message is to exchange the application identifiers supported as
512 described in [G698.2]. Please refer to the "draft-galikunze-ccamp-
513 g-698-2-snmp-mib-10". For more details about these parameters.
514 There can be more than one Application Identifier supported by the
515 OXC/OLS. The number of application identifiers supported is
516 exchanged in the "OCh_General" message. (from
517 [G698.1]/[G698.2]/[G959.1] and G.874.1 )
519 The parameters are
520 1. Number of Application Identifiers (A.I.) Supported
522 2. Single-channel application identifier Number
523 uniquely identifiers this entry - 8 bits
525 3. Application Indentifier Type (A.I.) (STANDARD/PROPRIETARY)
527 4. Single-channel application identifier -- 96 bits
528 (from [G698.1]/[G698.2]/[G959.1]
530 - this parameter can have
531 multiple instances as the transceiver can support multiple
532 application identifiers.
534 Figure 7: The format of the this sub-object (Type = TBA, Length =
535 TBA) is as follows:
537 0 1 2 3
538 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
539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
540 | Type | Length | (Reserved) |
541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
542 | Number of Application | |
543 | Identifiers Supported | (Reserved) |
544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
545 | Single-channel| A.I. Type | A.I. length |
546 | Application | | |
547 | Identifier | | |
548 | Number | | |
549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
550 | Single-channel Application Identifier |
551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
552 | Single-channel Application Identifier |
553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
554 | Single-channel Application Identifier |
555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
556 // .... //
557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
558 | Single-channel| | A.I. length |
559 | Application | A.I. Type | |
560 | Identifier | | |
561 | Number | | |
562 | | | |
563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
564 | Single-channel Application Identifier |
565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
566 | Single-channel Application Identifier |
567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
568 | Single-channel Application Identifier |
569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
571 A.I. Type in use: STANDARD, PROPRIETARY
573 A.I. Type in use: STANDARD
574 Refer to G.698.2 recommendation : B-DScW-ytz(v)
576 0 1 2 3
577 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
578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
579 | Single-channel Application Code |
580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
581 | Single-channel Application Code |
582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
583 | Single-channel Application Code |
584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
586 A.I. Type in use: PROPRIETARY
588 Note: if the A.I. type = PROPRIETARY, the first 6 Octets of the
589 Application Identifier in use are six characters of the
590 PrintableString must contain the Hexadecimal representation of
591 an OUI (Organizationally Unique Identifier) assigned to the
592 vendor whose implementation generated the Application
593 Identifier; the remaining octets of the PrintableString are
594 unspecified.
596 0 1 2 3
597 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
598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
599 | OUI |
600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
601 | OUI cont. | Vendor value |
602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
603 | Vendor Value |
604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
606 Figure 7: OCh_ApplicationIdentifier
608 6. OCh_Ss - OCh transmit parameters
610 These are the G.698.2 parameters at the Source(Ss reference points).
611 Please refer to "draft-galikunze-ccamp-g-698-2-snmp-mib-10" for more
612 details about these parameters.
614 1. Output power
616 Figure 8: The format of the OCh sub-object (Type = TBA, Length = TBA)
617 is as follows:
619 0 1 2 3
620 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
621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
622 | Type | Length | (Reserved) |
623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
624 | Output Power |
625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
627 Figure 8: OCh_Ss transmit parameters
629 7. OCh_Rs - receive parameters
631 These are the G.698.2 parameters at the Sink (Rs reference points).
632 Please refer to the "draft-galikunze-ccamp-g-698-2-snmp-mib-10" for
633 more details about these parameters.
635 1. Current Input Power - (0.1dbm) 4bytes
637 Figure 9: The format of the OCh receive sub-object (Type = TBA,
638 Length = TBA) is as follows:
640 The format of the OCh receive/OLS Sink sub-object (Type = TBA,
641 Length = TBA) is as follows:
643 0 1 2 3
644 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
645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
646 | Type | Length | (Reserved) |
647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
648 | Current Input Power |
649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
651 Figure 9: OCh_Rs receive parameters
653 8. Security Considerations
655 LMP message security uses IPsec, as described in [RFC4204]. This
656 document only defines new LMP objects that are carried in existing
657 LMP messages, similar to the LMP objects in [RFC:4209]. This
658 document does not introduce new security considerations.
660 9. IANA Considerations
662 LMP defines the following name spaces and
663 the ways in which IANA can make assignments to these namespaces:
665 - LMP Message Type
666 - LMP Object Class
667 - LMP Object Class type (C-Type) unique within the Object Class
668 - LMP Sub-object Class type (Type) unique within the Object Class
669 This memo introduces the following new assignments:
671 LMP Sub-Object Class names:
673 under DATA_LINK Class name (as defined in )
674 - OCh_General (sub-object Type = TBA)
675 - OCh_ApplicationIdentifier (sub-object Type = TBA)
676 - OCh_Ss (sub-object Type = TBA)
677 - OCh_Rs (sub-object Type = TBA)
679 10. Contributors
681 Arnold Mattheus
682 Deutsche Telekom
683 Darmstadt
684 Germany
685 email a.mattheus@telekom.de
687 John E. Drake
688 Juniper
689 1194 N Mathilda Avenue
690 HW-US,Pennsylvania
691 USA
692 jdrake@juniper.net
694 11. References
696 11.1. Normative References
698 [RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204,
699 October 2005.
701 [RFC4209] Fredette, A. and J. Lang, "Link Management Protocol (LMP)
702 for Dense Wavelength Division Multiplexing (DWDM) Optical
703 Line Systems", RFC 4209, October 2005.
705 [RFC6205] Otani, T. and D. Li, "Generalized Labels for Lambda-
706 Switch-Capable (LSC) Label Switching Routers", RFC 6205,
707 March 2011.
709 [RFC4054] Strand, J. and A. Chiu, "Impairments and Other Constraints
710 on Optical Layer Routing", RFC 4054, May 2005.
712 [ITU.G698.2]
713 International Telecommunications Union, "Amplified
714 multichannel dense wavelength division multiplexing
715 applications with single channel optical interfaces",
716 ITU-T Recommendation G.698.2, November 2009.
718 [ITU.G694.1]
719 International Telecommunications Union, ""Spectral grids
720 for WDM applications: DWDM frequency grid"", ITU-T
721 Recommendation G.698.2, February 2012.
723 [ITU.G709]
724 International Telecommunications Union, "Interface for the
725 Optical Transport Network (OTN)", ITU-T Recommendation
726 G.709, February 2012.
728 [ITU.G872]
729 International Telecommunications Union, "Architecture of
730 optical transport networks", ITU-T Recommendation G.872,
731 October 2012.
733 [ITU.G874.1]
734 International Telecommunications Union, "Optical transport
735 network (OTN): Protocol-neutral management information
736 model for the network element view", ITU-T Recommendation
737 G.874.1, October 2012.
739 11.2. Informative References
741 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
742 "Introduction and Applicability Statements for Internet-
743 Standard Management Framework", RFC 3410, December 2002.
745 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
746 June 1999.
748 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
749 Documents", BCP 111, RFC 4181, September 2005.
751 [I-D.kunze-g-698-2-management-control-framework]
752 Kunze, R., "A framework for Management and Control of
753 optical interfaces supporting G.698.2", draft-kunze-
754 g-698-2-management-control-framework-00 (work in
755 progress), July 2011.
757 Authors' Addresses
759 Dharini Hiremagalur (editor)
760 Juniper
761 1194 N Mathilda Avenue
762 Sunnyvale - 94089 California
763 USA
765 Phone: +1408
766 Email: dharinih@juniper.net
767 Gert Grammel (editor)
768 Juniper
769 Oskar-Schlemmer Str. 15
770 80807 Muenchen
771 Germany
773 Phone: +49 1725186386
774 Email: ggrammel@juniper.net
776 Gabriele Galimberti (editor)
777 Cisco
778 Via S. Maria Molgora, 48
779 20871 - Vimercate
780 Italy
782 Phone: +390392091462
783 Email: ggalimbe@cisco.com
785 Zafar Ali (editor)
786 Cisco
787 3000 Innovation Drive
788 KANATA
789 ONTARIO K2K 3E8
791 Email: zali@cisco.com
793 Ruediger Kunze (editor)
794 Deutsche Telekom
795 Dddd, xx
796 Berlin
797 Germany
799 Phone: +49xxxxxxxxxx
800 Email: RKunze@telekom.de
802 Dieter Beller (editor)
803 ALU
804 Lorenzstrasse, 10
805 70435 Stuttgart
806 Germany
808 Phone: +4971182143125
809 Email: Dieter.Beller@alcatel-lucent.com