1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
|
<pre>Network Working Group A. Fredette, Ed.
Request for Comments: 4209 Hatteras Networks
Category: Standards Track J. Lang, Ed.
Sonos Inc.
October 2005
<span class="h1">Link Management Protocol (LMP) for</span>
<span class="h1">Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Link Management Protocol (LMP) is defined to manage traffic
engineering (TE) links. In its present form, LMP focuses on peer
nodes, i.e., nodes that peer in signaling and/or routing. This
document proposes extensions to LMP to allow it to be used between a
peer node and an adjacent optical line system (OLS). These
extensions are intended to satisfy the "Optical Link Interface
Requirements" described in a companion document.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Networks are being developed with routers, switches, optical cross-
connects (OXCs), dense wavelength division multiplexing (DWDM)
optical line systems (OLSes), and add-drop multiplexors (ADMs) that
use a common control plane (e.g., Generalized MPLS (GMPLS)) to
dynamically provision resources and to provide network survivability
using protection and restoration techniques.
The Link Management Protocol (LMP) is being developed as part of the
GMPLS protocol suite to manage traffic engineering (TE) links
[<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>]. In its present form, LMP focuses on peer nodes, i.e.,
nodes that peer in signaling and/or routing (e.g., OXC-to-OXC, as
illustrated in Figure 1). In this document, extensions to LMP are
proposed to allow it to be used between a peer node and an adjacent
optical line system (OLS). These extensions are intended to satisfy
<span class="grey">Fredette & Lang Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4209">RFC 4209</a> LMP for DWDM Optical Line Systems October 2005</span>
the "Optical Link Interface Requirements" described in [<a href="#ref-OLI" title=""Optical Link Interface Requirements"">OLI</a>]. It is
assumed that the reader is familiar with LMP, as defined in
[<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>].
+------+ +------+ +------+ +------+
| | ----- | | | | ----- | |
| OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
| | ----- | | | | ----- | |
+------+ +------+ +------+ +------+
^ ^
| |
+---------------------LMP---------------------+
Figure 1: LMP Model
Consider two peer nodes (e.g., two OXCs) interconnected by a
wavelength-multiplexed link, i.e., a DWDM optical link (see Figure 1
above). Information about the configuration of this link and its
current state is known by the two OLSes (OLS1 and OLS2). Allowing
them to communicate this information to the corresponding peer nodes
(OXC1 and OXC2) via LMP can improve network usability by reducing
required manual configuration and by enhancing fault detection and
recovery.
Information about the state of LSPs using the DWDM optical link is
known by the peer nodes (OXC1 and OXC2), and allowing them to
communicate this information to the corresponding OLSes (OLS1 and
OLS2) is useful for alarm management and link monitoring. Alarm
management is important because the administrative state of an LSP,
known to the peer nodes (e.g., via the Admin Status object of GMPLS
signaling [<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>]), can be used to suppress spurious alarm
reporting from the OLSes.
The model for extending LMP to OLSes is shown in Figure 2.
+------+ +------+ +------+ +------+
| | ----- | | | | ----- | |
| OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
| | ----- | | | | ----- | |
+------+ +------+ +------+ +------+
^ ^ ^ ^ ^ ^
| | | | | |
| +-----LMP-----+ +-----LMP-----+ |
| |
+----------------------LMP-----------------------+
Figure 2: Extended LMP Model
<span class="grey">Fredette & Lang Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4209">RFC 4209</a> LMP for DWDM Optical Line Systems October 2005</span>
In this model, a peer node may have LMP sessions with adjacent OLSes,
as well as adjacent peer nodes. In Figure 2, for example, the OXC1-
OXC2 LMP session can be used to build traffic-engineering (TE) links
for GMPLS signaling and routing, as described in [<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>]. The
OXC1-OLS1 and the OXC2-OLS2 LMP sessions are used to exchange
information about the configuration of the DWDM optical link and its
current state and information about the state of LSPs using that
link.
The latter type of LMP sessions is discussed in this document. It is
important to note that a peer node may have LMP sessions with one or
more OLSes and an OLS may have LMP sessions with one or more peer
nodes.
Although there are many similarities between an LMP session between
two peer nodes and an LMP session between a peer node and an OLS,
there are some differences as well. The former type of LMP session
is used to provide the basis for GMPLS signaling and routing. The
latter type of LMP session is used to augment knowledge about the
links between peer nodes.
A peer node maintains its peer node-to-OLS LMP sessions and its peer
node-to-peer node LMP sessions independently. This means that it
MUST be possible for LMP sessions to come up in any order. In
particular, it MUST be possible for a peer node-to-peer node LMP
session to come up in the absence of any peer node-to-OLS LMP
sessions, and vice versa.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
The reader is assumed to be familiar with the terminology in
[<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>].
DWDM: Dense wavelength division multiplexing
OLS: Optical line system
Opaque:
A device is called X-opaque if it examines or modifies the X
aspect of the signal while forwarding an incoming signal from
input to output.
OXC: Optical cross-connect
<span class="grey">Fredette & Lang Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4209">RFC 4209</a> LMP for DWDM Optical Line Systems October 2005</span>
Transparent:
As defined in [<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>], a device is called X-transparent if it
forwards incoming signals from input to output without examining
or modifying the X aspect of the signal. For example, a Frame
Relay switch is network-layer transparent; an all-optical switch
is electrically transparent.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Scope of LMP-WDM Protocol</span>
This document focuses on extensions required for use with opaque
OLSes. In particular, this document is intended for use with OLSes
having SONET, SDH, and Ethernet user ports.
At the time of this writing, work is ongoing in the area of fully
transparent wavelength routing; however, it is premature to identify
the necessary information to be exchanged between a peer node and an
OLS in this context. Nevertheless, the protocol described in this
document provides the necessary framework in which to exchange
additional information that is deemed appropriate.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. LMP Extensions for Optical Line Systems</span>
LMP currently consists of four main procedures, of which the first
two are mandatory and the last two are optional:
1. Control channel management
2. Link property correlation
3. Link verification
4. Fault management
All four functions are supported in LMP-WDM.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Control Channel Management</span>
As in [<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>], we do not specify the exact implementation of the
control channel; it could be, for example, a separate wavelength,
fiber, Ethernet link, an IP tunnel routed over a separate management
network, a multi-hop IP network, or the overhead bytes of a data
link.
The control channel management for a peer node-to-OLS link is the
same as for a peer node-to-peer node link, as described in [<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>].
To distinguish between a peer node-to-OLS LMP session and a peer
node-to-peer node LMP session, a new LMP-WDM CONFIG object is defined
(C-Type = 2). The format of the CONFIG object is as follows:
<span class="grey">Fredette & Lang Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4209">RFC 4209</a> LMP for DWDM Optical Line Systems October 2005</span>
Class = 6
o C-Type = 2, LMP-WDM_CONFIG
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|W|O| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
WDM: 1 bit
This bit indicates support for the LMP-WDM extensions defined
in this document.
OLS: 1 bit
If set, this bit indicates that the sender is an optical line
system (OLS). If clear, this bit indicates that the sender is
a peer node.
The LMP-WDM extensions are designed for peer node-to-OLS LMP
sessions. The OLS bit allows a node to identify itself as an OLS or
a peer node. This is used to detect misconfiguration of a peer
node-to-OLS LMP session between two peer nodes or a peer node-to-peer
node LMP session between a peer node and an OLS.
If the node does not support the LMP-WDM extensions, it MUST reply to
the Config message with a ConfigNack message.
If a peer node that is configured to run LMP-WDM receives a Config
message with the OLS bit clear in LMP-WDM_CONFIG object, it MUST
reply to the Config message with a ConfigNack message.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Link Verification</span>
The Test procedure used with OLSes is the same as described in
[<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>]. The VerifyTransportMechanism (included in the BeginVerify
and BeginVerifyAck messages) is used to allow nodes to negotiate a
link verification method and is essential for line systems that have
access to overhead bytes rather than the payload. The VerifyId
(provided by the remote node in the BeginVerifyAck message and used
in all subsequent Test messages) is used to differentiate Test
messages from different LMP Link Verification procedures. In
<span class="grey">Fredette & Lang Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4209">RFC 4209</a> LMP for DWDM Optical Line Systems October 2005</span>
addition to the Test procedure described in [<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>], the trace
monitoring function of [<a href="./rfc4207" title=""Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages"">RFC4207</a>] may be used for link verification
when the OLS user ports are SONET or SDH.
In a combined LMP and LMP-WDM context, there is an interplay between
the data links being managed by peer node-to-peer node LMP sessions
and peer node-to-OLS LMP sessions. For example, in Figure 2, the
OXC1-OLS1 LMP session manages the data links between OXC1 and OLS1,
and the OXC2-OLS2 LMP session manages the data links between OXC2 and
OLS2. However, the OXC1-OXC2 LMP session manages the data links
between OXC1 and OXC2, which are actually a concatenation of the data
links between OXC1 and OLS1, the DWDM span between OLS1 and OLS2, and
the data links between OXC2 and OLS2. It is these concatenated links
that comprise the TE links that are advertised in the GMPLS TE link
state database.
The implication of this is that when the data links between OXC1 and
OXC2 are being verified, using the LMP link verification procedure,
OLS1 and OLS2 need to make themselves transparent with respect to
these concatenated data links. The coordination of verification of
OXC1-OLS1 and OXC2-OLS2 data links to ensure this transparency is the
responsibility of the peer nodes, OXC1 and OXC2.
It is also necessary for these peer nodes to understand the mappings
between the data links of the peer node - OLS LMP session and the
concatenated data links of the peer node - peer node LMP session.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Link Summarization</span>
As in [<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>], the LinkSummary message is used to synchronize the
Interface_Ids and correlate the properties of the TE link. (Note
that the term "TE link" originated from routing/signaling
applications of LMP, and this concept does not necessarily apply to
an OLS. However, the term is used in this document to remain
consistent with LMP terminology.) The LinkSummary message includes
one or more DATA_LINK objects. The contents of the DATA_LINK object
consist of a series of variable-length data items called Data Link
sub-objects describing the capabilities of the data links.
In this document, several additional Data Link sub-objects are
defined to describe additional link characteristics. The link
characteristics are, in general, those needed by the CSPF to select
the path for a particular LSP. These link characteristics describe
the specified peer node-to-OLS data link, as well as the associated
DWDM span between the two OLSes.
<span class="grey">Fredette & Lang Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4209">RFC 4209</a> LMP for DWDM Optical Line Systems October 2005</span>
The format of the Data Link sub-objects follows the format described
in [<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>] and is shown below for readability:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
| Type | Length | (Sub-object contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
Type: 8 bits
The Type indicates the type of contents of the sub-object.
Length: 8 bits
The Length field contains the total length of the sub-object in
bytes, including the Type and Length fields. The Length MUST
be at least 4, and MUST be a multiple of 4.
The following link characteristics are exchanged on a per data link
basis.
<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>. Link Group ID</span>
The main purpose of the Link Group ID is to reduce control traffic
during failures that affect many data links. A local ID may be
assigned to a group of data links. This ID can be used to reduce the
control traffic in the event of a failure by enabling a single
ChannelStatus message with the LINK GROUP CHANNEL_STATUS object (see
<a href="#section-2.4.1">Section 2.4.1</a>) to be used for a group of data links instead of
individual ChannelStatus messages for each data link. A data link
may be a member of multiple groups. This is achieved by including
multiple Link Group ID sub-objects in the LinkSummary message.
The Link Group ID feature allows Link Groups to be assigned based on
the types of fault correlation and aggregation supported by a given
OLS. From a practical perspective, the Link Group ID is used to map
(or group) data links into "failable entities" known primarily to the
OLS. If one of those failable entities fails, all associated data
links are failed and the peer node is notified with a single message.
For example, an OLS could create a Link Group for each laser in the
OLS. The data links associated with each laser would then each be
assigned the Link Group ID for that laser. If a laser fails, the OLS
would then report a single failure affecting all of the data links
with a Link Group ID of the failed laser. The peer node that
receives the single failure notification then knows which data links
are affected. Similarly, an OLS could create a Link Group ID for a
<span class="grey">Fredette & Lang Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4209">RFC 4209</a> LMP for DWDM Optical Line Systems October 2005</span>
fiber, to report a failure affecting all of the data links associated
with that fiber if a loss-of-signal (LOS) is detected for that fiber.
The format of the Link Group ID sub-object (Type = 3, Length = 8) 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
Link Group ID: 32 bits
Link Group ID 0xFFFFFFFF is reserved and indicates all data
links in a TE link. All data links are members of Link Group
0xFFFFFFFF by default.
<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a>. Shared Risk Link Group (SRLG) Identifier</span>
This identifies the SRLGs of which the data link is a member. This
information may be configured on an OLS by the user and used for
diverse path computation (see [<a href="./rfc4202" title=""Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4202</a>]).
The format of the SRLG sub-object (Type = 4, Length = (N+1)*4 where N
is the number of SRLG values) 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #(N-1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
<span class="grey">Fredette & Lang Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4209">RFC 4209</a> LMP for DWDM Optical Line Systems October 2005</span>
Shared Risk Link Group Value: 32 bits
See [<a href="./rfc4202" title=""Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4202</a>]. List as many SRLGs as apply.
<span class="h4"><a class="selflink" id="section-2.3.3" href="#section-2.3.3">2.3.3</a>. Bit Error Rate (BER) Estimate</span>
This object provides an estimate of the BER for the data link.
The Bit Error Rate (BER) is the proportion of bits that have errors
relative to the total number of bits received in a transmission,
usually expressed as ten to a negative power. For example, a
transmission might have a BER of "10 to the minus 13", meaning that,
out of every 10,000,000,000,000 bits transmitted, one bit may be in
error. The BER is an indication of overall signal quality.
The format of the BER Estimate sub-object (Type = 5; Length = 4) 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 | BER | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
BER: 8 bits
The exponent from the BER representation described above. That
is, if the BER is 10 to the minus X, the BER field is set to X.
<span class="h4"><a class="selflink" id="section-2.3.4" href="#section-2.3.4">2.3.4</a>. Optical Protection</span>
This indicates whether the link is protected by the OLS. This
information can be used as a measure of link capability. It may be
advertised by routing and used by signaling as a selection criterion,
as described in [<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>].
The format of the Optical Protection sub-object (Type = 6; Length =
4) 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) | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
<span class="grey">Fredette & Lang Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4209">RFC 4209</a> LMP for DWDM Optical Line Systems October 2005</span>
Link Flags: 6 bits
Encoding for Link Flags is defined in <a href="./rfc3471#section-7">Section 7 of [RFC3471]</a>.
<span class="h4"><a class="selflink" id="section-2.3.5" href="#section-2.3.5">2.3.5</a>. Total Span Length</span>
This indicates the total distance of fiber in the OLS. This may be
used as a routing metric or to estimate delay.
The format of the Total Span Length sub-object (Type = 7, Length = 8)
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Span Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
Span Length: 32 bits
This value represents the total length of the WDM span in
meters, expressed as an unsigned (long) integer.
<span class="h4"><a class="selflink" id="section-2.3.6" href="#section-2.3.6">2.3.6</a>. Administrative Group (Color)</span>
The administrative group (or Color) to which the data link belongs.
The format of the Administrative Group sub-object (Type = 8, Length =
8) 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
Administrative Group: 32 bits
A 32-bit value, as defined in [<a href="./rfc3630" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">RFC3630</a>].
<span class="grey">Fredette & Lang Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4209">RFC 4209</a> LMP for DWDM Optical Line Systems October 2005</span>
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Fault Management</span>
The Fault Management procedure used between a peer and an OLS follows
the procedures described in [<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>]; some further extensions are
defined in this section. The information learned from the OLS-peer
fault management procedures may be used to trigger peer-peer LMP
fault management, or may be used to trigger GMPLS signaling/routing
procedures directly.
Fault management consists of three major functions:
1. Fault Detection
2. Fault Localization
3. Fault Notification
The fault detection mechanisms are the responsibility of the
individual nodes and are not specified as part of this protocol.
Fault detection mechanisms may include a Bit Error Rate (BER)
exceeding a threshold, and loss-of-signal (LOS) and SONET/SDH-level
errors. It is the responsibility of the OLS to translate these
failures into (Signal) OK, Signal Failure (SF), or Signal Degrade
(SD), as described in [<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>].
That is, an OLS uses the messages defined in the LMP fault
localization procedures (ChannelStatus, ChannelStatusAck,
ChannelStatusRequest, and ChannelStatusResponse messages) to inform
the adjacent peer node of failures it has detected, in order to
initiate the LMP fault localization procedures between peer nodes,
but it does not participate in those procedures.
The OLS may also execute its own fault localization process to allow
it to determine the location of the fault along the DWDM span. For
example, the OLS may be able to pinpoint the fault to a particular
amplifier in a span of thousands of kilometers in length.
To report data link failures and recovery conditions, LMP-WDM uses
the ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and
ChannelStatusResponse messages defined in [<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>].
Each data link is identified by an Interface_ID. In addition, a Link
Group ID may be assigned to a group of data links (see <a href="#section-2.3.1">Section</a>
<a href="#section-2.3.1">2.3.1</a>). The Link Group ID may be used to reduce the control traffic
by providing channel status information for a group of data links. A
new LINK GROUP CHANNEL_STATUS object is defined below for this
purpose. This object may be used in place of the CHANNEL_STATUS
objects described in [<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>] in the ChannelStatus message.
<span class="grey">Fredette & Lang Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4209">RFC 4209</a> LMP for DWDM Optical Line Systems October 2005</span>
<span class="h4"><a class="selflink" id="section-2.4.1" href="#section-2.4.1">2.4.1</a>. LINK_GROUP CHANNEL_STATUS Object</span>
The LINK_GROUP CHANNEL_STATUS object is used to indicate the status
of the data links belonging to a particular Link Group. The
correlation of data links to Group ID is made with the Link Group ID
sub-object of the DATA_LINK object.
The format of the LINK_GROUP CHANNEL_STATUS object is as follows
(Class = 13, C-Type = 4):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link Group ID: 32 bits
The Link Group ID 0xFFFFFFFF is reserved and indicates all data
links in a TE link. All data links are members of the Link
Group 0xFFFFFFFF by default.
Channel Status: 32 bits
The values for the Channel Status field are defined in
[<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>].
This object is non-negotiable.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Security Considerations</span>
LMP message security uses IPsec, as described in [<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>]. This
document only defines new LMP objects that are carried in existing
LMP messages. As such, this document introduces no other new
security considerations not covered in [<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>].
<span class="grey">Fredette & Lang Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4209">RFC 4209</a> LMP for DWDM Optical Line Systems October 2005</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
LMP [<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>] 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 Object Class Types:
o under CONFIG class name (as defined in [<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>])
- LMP-WDM_CONFIG (C-Type = 2)
o under CHANNEL_STATUS class name (as defined in [<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>])
- LINK_GROUP (C-Type = 4)
LMP Sub-Object Class names:
o under DATA_LINK Class name (as defined in [<a href="./rfc4204" title=""The Link Management Protocol (LMP)"">RFC4204</a>])
- Link_GroupId (sub-object Type = 3)
- SRLG (sub-object Type = 4)
- BER_Estimate (sub-object Type = 5)
- Optical_Protection (sub-object Type = 6)
- Total_Span_Length (sub-object Type = 7)
- Administrative_Group (sub-object Type = 8)
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Contributors</span>
The authors would like to acknowledge Osama S. Aboul-Magd, Stuart
Brorson, Sudheer Dharanikota, John Drake, David Drysdale, W. L.
Edwards, Adrian Farrel, Andre Fredette, Rohit Goyal, Hirokazu
Ishimatsu, Monika Jaeger, Ram Krishnan, Jonathan P. Lang, Raghu
Mannam, Eric Mannie, Dimitri Papadimitriou, Jagan Shantigram, Ed
Snyder, George Swallow, Gopala Tumuluri, Yong Xue, Lucy Yong, and
John Yu.
<span class="grey">Fredette & Lang Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4209">RFC 4209</a> LMP for DWDM Optical Line Systems October 2005</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-RFC4202">RFC4202</a>] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", <a href="./rfc4202">RFC 4202</a>, September 2005.
[<a id="ref-RFC4204">RFC4204</a>] Lang, J., Ed., "The Link Management Protocol (LMP)", <a href="./rfc4204">RFC</a>
<a href="./rfc4204">4204</a>, September 2005.
[<a id="ref-RFC4207">RFC4207</a>] Lang, J., and D. Papadimitriou, "Synchronous Optical
Network (SONET)/Synchronous Digital Hierarchy (SDH)
Encoding for Link Management Protocol (LMP) Test
Messages", <a href="./rfc4207">RFC 4207</a>, September 2005.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3471">RFC3471</a>] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", <a href="./rfc3471">RFC 3471</a>,
January 2003.
[<a id="ref-RFC3630">RFC3630</a>] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", <a href="./rfc3630">RFC 3630</a>,
September 2003.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-OLI">OLI</a>] Fredette, A., Editor, "Optical Link Interface
Requirements", Work in Progress.
<span class="grey">Fredette & Lang Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4209">RFC 4209</a> LMP for DWDM Optical Line Systems October 2005</span>
Editors' Addresses
Andre Fredette
Hatteras Networks
P.O. Box 110025
Research Triangle Park
NC 27709-0025, USA
EMail: Afredette@HatterasNetworks.com
Jonathan P. Lang
Sonos, Inc.
223 E. De La Guerra St.
Santa Barbara, CA 93101
EMail: jplang@ieee.org
<span class="grey">Fredette & Lang Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4209">RFC 4209</a> LMP for DWDM Optical Line Systems October 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Fredette & Lang Standards Track [Page 16]
</pre>
|
