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
|
<pre>Internet Engineering Task Force (IETF) D. Li
Request for Comments: 5818 H. Xu
Category: Standards Track Huawei
ISSN: 2070-1721 S. Bardalai
Fujitsu
J. Meuric
France Telecom
D. Caviglia
Ericsson
April 2010
<span class="h1">Data Channel Status Confirmation Extensions</span>
<span class="h1">for the Link Management Protocol</span>
Abstract
This document defines simple additions to the Link Management
Protocol (LMP) to provide a control plane tool that can assist in the
location of stranded resources by allowing adjacent Label-Switching
Routers (LSRs) to confirm data channel statuses and provide triggers
for notifying the management plane if any discrepancies are found.
As LMP is already used to verify data plane connectivity, it is
considered to be an appropriate candidate to support this feature.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc5818">http://www.rfc-editor.org/info/rfc5818</a>.
<span class="grey">Li et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5818">RFC 5818</a> Data Channel Statuses and LMP April 2010</span>
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Specification of Requirements ...................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Problem Explanation .............................................<a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Mismatch Caused by Manual Configuration ....................<a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. Mismatch Caused by LSP Deletion ............................<a href="#page-5">5</a>
<a href="#section-3.3">3.3</a>. Failed Resources ...........................................<a href="#page-6">6</a>
<a href="#section-4">4</a>. Motivation ......................................................<a href="#page-6">6</a>
<a href="#section-5">5</a>. Extensions to LMP ...............................................<a href="#page-7">7</a>
<a href="#section-5.1">5.1</a>. Confirm Data Channel Status Messages .......................<a href="#page-7">7</a>
<a href="#section-5.1.1">5.1.1</a>. ConfirmDataChannelStatus Messages ...................<a href="#page-8">8</a>
<a href="#section-5.1.2">5.1.2</a>. ConfirmDataChannelStatusAck Messages ................<a href="#page-8">8</a>
<a href="#section-5.1.3">5.1.3</a>. ConfirmDataChannelStatusNack Messages ...............<a href="#page-8">8</a>
<a href="#section-5.2">5.2</a>. Data Channel Status Subobject ..............................<a href="#page-9">9</a>
<a href="#section-5.3">5.3</a>. Message Construction ......................................<a href="#page-10">10</a>
<a href="#section-5.4">5.4</a>. Backward Compatibility ....................................<a href="#page-10">10</a>
<a href="#section-6">6</a>. Procedures .....................................................<a href="#page-11">11</a>
<a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-12">12</a>
<a href="#section-8">8</a>. IANA Considerations ............................................<a href="#page-12">12</a>
<a href="#section-8.1">8.1</a>. LMP Message Types .........................................<a href="#page-12">12</a>
<a href="#section-8.2">8.2</a>. LMP Data Link Object Subobject ............................<a href="#page-13">13</a>
<a href="#section-8.3">8.3</a>. LMP Error_Code Class Type .................................<a href="#page-13">13</a>
<a href="#section-9">9</a>. Acknowledgments ................................................<a href="#page-13">13</a>
<a href="#section-10">10</a>. References ....................................................<a href="#page-13">13</a>
<a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-13">13</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-14">14</a>
Contributor's Address .............................................<a href="#page-14">14</a>
<span class="grey">Li et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5818">RFC 5818</a> Data Channel Statuses and LMP April 2010</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Generalized Multiprotocol Label Switching (GMPLS) networks are
constructed from Traffic Engineering (TE) links connecting Label
Switching Routers (LSRs). The TE links are constructed from a set of
data channels. In this context, a data channel corresponds to a
resource label in a non-packet technology (such as a timeslot or a
lambda).
A data channel status mismatch exists if the LSR at one end of a TE
link believes that the data channel is assigned to carry data, but
the LSR at the other end does not. The term "ready to carry data"
means cross-connected or bound to an end-point for the receipt or
delivery of data.
Data channel mismatches cannot be detected from the TE information
advertised by the routing protocols [<a href="./rfc4203" title=""OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4203</a>], [<a href="./rfc5307" title=""IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC5307</a>]. The
existence of some data channel mismatch problems may be detected by a
mismatch in the advertised bandwidths where bidirectional TE links
and bidirectional services are in use. However, where unidirectional
services exist, or where multiple data channel mismatches occur, it
is not possible to detect such errors through the routing protocol-
advertised TE information. In any case, there is no mechanism to
isolate the mismatches by determining which data channels are at
fault.
If a data channel mismatch exists, any attempt to use the data
channel for a new Label Switched Path (LSP) will fail. One end of
the TE link may attempt to assign the TE link for use, but the other
end will report the data channel as unavailable when the control
plane or management plane attempts to assign it to an LSP.
Although such a situation can be resolved through the use of the
Acceptable Label Set object in GMPLS signaling [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>], such a
procedure is inefficient since it may require an additional signaling
exchange for each LSP that is set up. When many LSPs are to be set
up, and when there are many data channel mismatches, such
inefficiencies become significant. It is desirable to avoid the
additional signaling overhead, and to report the problems to the
management plane so that they can be resolved to improve the
efficiency of LSP setup.
Correspondingly, such a mismatch situation may give rise to
misconnections in the data plane, especially when LSPs are set up
using management plane operations.
<span class="grey">Li et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5818">RFC 5818</a> Data Channel Statuses and LMP April 2010</span>
Resources (data channels) that are in a mismatched state are often
described as "stranded resources". They are not in use for any LSP,
but they cannot be assigned for use by a new LSP because they appear
to be in use. Although it is theoretically possible for management
plane applications to audit all network resources to locate stranded
resources and to release them, this process is rarely performed
because of the difficulty of coordinating different Element
Management Systems (EMSs) and the associated risks of accidentally
releasing in-use resources. It is desirable to have a control plane
mechanism that detects and reports stranded resources.
This document defines simple additions to the Link Management
Protocol (LMP) [<a href="./rfc4204" title=""Link Management Protocol (LMP)"">RFC4204</a>] to provide a control plane tool that can
assist in the location of stranded resources by allowing adjacent
LSRs to confirm data channel statuses and provide triggers for
notifying the management plane if any discrepancies are found. As
LMP is already used to verify data plane connectivity, it is
considered to be an appropriate candidate to support this feature.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Specification of Requirements</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>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Problem Explanation</span>
Examples of data channel mismatches are described in the following
three scenarios.
In all of the scenarios, the specific channel resource of a data link
will be unavailable because of the data channel status mismatch, and
this channel resource will be wasted. Furthermore, a data channel
status mismatch may reduce the possibility of successful LSP
establishment, because a data channel status mismatch may result in
failure when establishing an LSP.
So it is desirable to confirm the data channel statuses as early as
possible.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Mismatch Caused by Manual Configuration</span>
The operator may have configured a cross-connect at only one end of a
TE link using an EMS. The resource at one end of the data channel is
allocated, but the corresponding resource is still available at the
other end of the same data channel. In this case, the data channel
may appear to be available for use by the control plane when viewed
from one end of the TE link but, will be considered to be unavailable
<span class="grey">Li et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5818">RFC 5818</a> Data Channel Statuses and LMP April 2010</span>
by the other end of the TE link. Alternatively, the available end of
the data channel may be cross-connected by the management plane, and
a misconnection may result from the fact that the other end of the
data channel is already cross-connected.
Figure 1 shows a data channel between nodes A and B. The resource at
A's end of the TE link is allocated through manual configuration,
while the resource at B's end of the TE link is available, so the
data channel status is mismatched.
allocated available
+-+------------+-+
A |x| | | B
+-+------------+-+
data channel
Figure 1. Mismatch Caused by Manual Configuration
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Mismatch Caused by LSP Deletion</span>
The channel status of a data link may become mismatched during the
LSP deletion process. If the LSP deletion process is aborted in the
middle of the process (perhaps because of a temporary control plane
failure), the cross-connect at the upstream node may be removed while
the downstream node still keeps its cross-connect, if the LSP
deletion was initiated by the source node.
For example, in Figure 2, an LSP traverses nodes A, B, and C. Node B
resets abnormally when the LSP is being deleted. This results in the
cross-connects of nodes A and C being removed, but the cross-connect
of node B still being in use. So, the data channel statuses between
nodes A and B, and between nodes B and C are both mismatched.
<---------LSP--------->
+-+-------+-+-------+-+
| | |X| | |
+-+-------+-+-------+-+
A B C
Figure 2. Mismatch Caused by LSP Deletion
In [<a href="./rfc2205" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RFC2205</a>] and [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>], a "soft state" mechanism was defined to
prevent state discrepancies between LSRs. Resource ReSerVation
Protocol-Traffic Engineering (RSVP-TE) restart processes ([<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>],
[<a href="./rfc5063" title=""Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart"">RFC5063</a>]) have been defined: adjacent LSRs may resynchronize their
control plane state to reinstate information about LSPs that have
persisted in the data plane. Both mechanisms aim at keeping state
consistency among nodes and allow LSRs to detect mismatched data
<span class="grey">Li et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5818">RFC 5818</a> Data Channel Statuses and LMP April 2010</span>
plane states. The data plane handling of such mismatched states can
be treated as a local policy decision. Some deployments may decide
to automatically clean up the data plane state so it matches the
control plane state, but others may choose to raise an alert to the
management plane and leave the data plane untouched just in case it
is in use.
In such cases, data channel mismatches may arise after restart and
might not be cleared up by the restart procedures.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Failed Resources</span>
Even if the situation is not common, it might happen that a
termination point of a TE link is seen as failed by one end, while on
the other end it is seen as OK. This problem may arise due to some
failure either in the hardware or in the status detection of the
termination point.
This mismatch in the termination point status can lead to failure in
the case of bidirectional LSP setup.
Good Failed
+-+------------+-+
A | | |X| B
+-+------------+-+
data channel
Path Message with Upstream Label---->
Figure 3. Mismatch Caused by Resource Failure
In this case, the upstream node chooses to use termination point A in
order to receive traffic from the downstream node. From the upstream
node's point of view, the resource is available and thus usable;
however, in the downstream node, the corresponding termination point
(resource B) is broken. This leads to a setup failure.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Motivation</span>
The requirement does not come from a lack in GMPLS specifications
themselves but rather from operational concerns because, in most
cases, GMPLS-controlled networks will co-exist with legacy networks
and legacy procedures.
The protocol extensions defined in this document are intended to
detect data plane problems resulting from misuse or misconfigurations
triggered by user error, or resulting from failure to clean up the
data plane after control plane disconnection. It is anticipated that
human mistakes are probably the major source of errors to deal with.
<span class="grey">Li et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5818">RFC 5818</a> Data Channel Statuses and LMP April 2010</span>
This document is not intened to provide a protocol mechanism to deal
with broken implementations.
The procedures defined in this document are designed to be performed
on a periodic or on-demand basis. It is NOT RECOMMENDED that the
procedures be used to provide a continuous and on-line monitoring
process.
As LMP is already used to verify data plane connectivity, it is
considered to be an appropriate candidate to support this feature.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Extensions to LMP</span>
A control plane tool to detect and isolate data channel mismatches is
provided in this document by simple additions to the Link Management
Protocol (LMP) [<a href="./rfc4204" title=""Link Management Protocol (LMP)"">RFC4204</a>]. It can assist in the location of stranded
resources by allowing adjacent LSRs to confirm data channel statuses.
Outline procedures are described in this section. More detailed
procedures are found in <a href="#section-6">Section 6</a>.
The message formats in the subsections that follow use Backus-Naur
Form (BNF) encoding as defined in [<a href="./rfc5511" title=""Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications"">RFC5511</a>].
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Confirm Data Channel Status Messages</span>
Extensions to LMP to confirm a data channel status are described
below. In order to confirm a data channel status, the new LMP
messages are sent between adjacent nodes periodically or driven by
some event (such as an operator command, a configurable timer, or the
rejection of an LSP setup message because of an unavailable
resource). The new LMP messages run over the control channel,
encapsulated in UDP with an LMP port number and IP addressing as
defined in "Link Management Protocol (LMP)" [<a href="./rfc4204" title=""Link Management Protocol (LMP)"">RFC4204</a>].
Three new messages are defined to check data channel status:
ConfirmDataChannelStatus, ConfirmDataChannelStatusAck, and
ConfirmDataChannelStatusNack. These messages are described in detail
in the following subsections. Message Type numbers are found in
<a href="#section-8.1">Section 8.1</a>.
<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>. ConfirmDataChannelStatus Messages</span>
The ConfirmDataChannelStatus message is used to provide the remote
end of the data channel with the status of the local end of the data
channel and to ask the remote end to report its data channel. The
message may report on (and request information about) more than one
data channel.
<span class="grey">Li et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5818">RFC 5818</a> Data Channel Statuses and LMP April 2010</span>
<ConfirmDataChannelStatus Message> ::= <Common Header>
<LOCAL_LINK_ID>
<MESSAGE_ID>
<DATA_LINK>[<DATA_LINK>...]
When a node receives the ConfirmDataChannelStatus message, and the
data channel status confirmation procedure is supported at the node,
the node compares its own data channel statuses with all of the data
channel statuses sent by the remote end in the
ConfirmDataChannelStatus message. If a data channel status mismatch
is found, this mismatch result is expected to be reported to the
management plane for further action. Management plane reporting
procedures and actions are outside the scope of this document.
If the message is a Confirm Data Channel Status message, and the
MESSAGE_ID value is less than the largest MESSAGE_ID value previously
received from the sender for the specified TE link, then the message
SHOULD be treated as being out-of-order.
<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>. ConfirmDataChannelStatusAck Messages</span>
The ConfirmDataChannelStatusAck message is sent back to the node that
originated the ConfirmDataChannelStatus message to return the
requested data channel statuses.
When the ConfirmDataChannelStatusAck message is received, the node
compares the received data channel statuses at the remote end with
those at the local end (the same operation as performed by the
receiver of the ConfirmDataChannelStatus message). If a data channel
status mismatch is found, the mismatch result is expected to be
reported to the management plane for further action.
<ConfirmDataChannelStatusAck Message> ::= <Common Header>
<MESSAGE_ID_ACK>
<DATA_LINK>[<DATA_LINK>...]
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the
ConfirmDataChannelStatus message being acknowledged.
Note that the ConfirmDataChannelStatusAck message is used both when
the data channel statuses match and when they do not match.
<span class="h4"><a class="selflink" id="section-5.1.3" href="#section-5.1.3">5.1.3</a>. ConfirmDataChannelStatusNack Messages</span>
When a node receives the ConfirmDataChannelStatus message, if the
data channel status confirmation procedure is not supported but the
message is recognized, a ConfirmDataChannelStatusNack message
<span class="grey">Li et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5818">RFC 5818</a> Data Channel Statuses and LMP April 2010</span>
containing an ERROR_CODE indicating "Channel Status Confirmation
Procedure not supported" MUST be sent.
If the data channel status confirmation procedure is supported, but
the node is unable to begin the procedure, a
ConfirmDataChannelStatusNack message containing an ERROR_CODE
indicating "Unwilling to Confirm" MUST be sent. If a
ConfirmDataChannelStatusNack message is received with such an
ERROR_CODE, the node that originated the ConfirmDataChannelStatus
message MAY schedule the ConfirmDataChannelStatus message
retransmission after a configured time. A default value of
10 minutes is suggested for this timer.
<ConfirmDataChannelStatusNack Message> ::= <Common Header>
[<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK>
<ERROR_CODE>
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the
ConfirmDataChannelStatus message being rejected.
The ERROR_CODE object in this message has a new Class Type (see
<a href="#section-8.3">Section 8.3</a>), but is formed as the ERROR_CODE object defined in
[<a href="./rfc4204" title=""Link Management Protocol (LMP)"">RFC4204</a>]. The following Error Codes are defined:
0x01 = Channel Status Confirmation Procedure not supported
0x02 = Unwilling to Confirm
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Data Channel Status Subobject</span>
A new Data Channel Status subobject type is introduced to the DATA
LINK object to hold the Data Channel Status and Data Channel ID.
See <a href="#section-8.2">Section 8.2</a> for the Subobject Type value.
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 | Data Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Data Channel ID //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<span class="grey">Li et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5818">RFC 5818</a> Data Channel Statuses and LMP April 2010</span>
Data Channel Status:
This is a series of bit flags to indicate the status of the data
channel. The following values are defined.
0x0000 : The channel is available/free.
0x0001 : The channel is unavailable/in-use.
Data Channel ID
This identifies the data channel. The length of this field can be
deduced from the Length field in the subobject. Note that all
subobjects must be padded to a four-byte boundary with trailing
zeros.
If such padding is required, the Length field MUST indicate the
length of the subobject up to, but not including, the first byte of
padding. Thus, the amount of padding is deduced and not represented
in the Length field.
Note that the Data Channel ID is given in the context of the sender
of the ConfirmChannelStatus message.
The Data Channel ID must be encoded as a label value. Based on the
type of signal (e.g., Synchronous Optical Network/Synchronous Digital
Hierarchy (SONET/SDH), Lambda, etc.), the encoding methodology
used will be different. For SONET/SDH, the label value is encoded as
per [<a href="./rfc4606" title=""Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control"">RFC4606</a>].
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Message Construction</span>
Data_Link Class (as defined in <a href="./rfc4204#section-13.12">Section 13.12 of [RFC4204]</a>) is
included in ConfirmDataChannelStatus and ConfirmDataChannelStatusAck
messages.
The status of the TE link end MUST be carried by the Data Channel
Status subobject, which is defined in <a href="#section-5.2">Section 5.2</a> of this document.
The new subobject MUST be part of Data_Link Class.
In the case of SONET/SDH, the Data Channel ID in the new subobject
SHOULD be used to identify each timeslot of the data link.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Backward Compatibility</span>
Some nodes running in the network might only support the LMP Message
Types, which are already defined in [<a href="./rfc4204" title=""Link Management Protocol (LMP)"">RFC4204</a>]. The three new types
of LMP messages defined in this document cannot be recognized by
these nodes. The behavior of an LMP node that receives an unknown
<span class="grey">Li et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5818">RFC 5818</a> Data Channel Statuses and LMP April 2010</span>
message is not specified in [<a href="./rfc4204" title=""Link Management Protocol (LMP)"">RFC4204</a>] and will be clarified in a
separate document.
Since the behavior of legacy nodes must be assumed to be unknown,
this document assumes that a deployment intended to support the
function described in this document will consist completely of nodes
that support the protocol extensions also described in this document.
In the future, it may be the case that LMP will be extended to allow
function support to be detected. In that case, it may become
possible to deploy this function in a mixed environment.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Procedures</span>
Adjacent nodes MAY send data channel status confirmation-related LMP
messages. Periodical timers or some other events requesting the
confirmation of channel status for the data link may trigger these
messages. It's a local policy decision to start the data channel
status confirmation process. The procedure is described below:
. Initially, the SENDER constructs a ConfirmDataChannelStatus
message that MUST contain one or more DATA_LINK objects. The
DATA_LINK object is defined in [<a href="./rfc4204" title=""Link Management Protocol (LMP)"">RFC4204</a>]. Each DATA_LINK object
MUST contain one or more Data Channel Status subobjects. The Data
Channel ID field in the Data Channel Status subobject MUST
indicate which data channel needs to be confirmed, and MUST report
the data channel status at the SENDER. The
ConfirmDataChannelStatus message is sent to the RECEIVER.
. Upon receipt of a ConfirmDataChannelStatus message, the RECEIVER
MUST extract the data channel statuses from the
ConfirmDataChannelStatus message and SHOULD compare these with its
data channel statuses for the reported data channels. If a data
channel status mismatch is found, the mismatch result SHOULD be
reported to the management plane for further action. The RECEIVER
also SHOULD send the ConfirmDataChannelStatusAck message, which
MUST carry all the local end statuses of the requested data
channels to the SENDER.
. If the RECEIVER is not able to support or to begin the
confirmation procedure, the RECEIVER MUST send a
ConfirmDataChannelStatusNack message containing the ERROR_CODE
that indicates the reason for rejection.
. Upon receipt of a ConfirmDataChannelStatusAck message, the SENDER
MUST compare the received data channel statuses at the remote end
with the data channel statuses at the local end. If a data
<span class="grey">Li et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5818">RFC 5818</a> Data Channel Statuses and LMP April 2010</span>
channel status mismatch is found, the mismatch result SHOULD be
reported to the management plane for further action.
The data channel status mismatch issue identified by LMP may be
automatically resolved by RSVP restart. For example, the restarting
node may also have damaged its data plane. This leaves the data
channels mismatched. However, RSVP restart will re-install the data
plane state in the restarting node. The issue may also be resolved
via RSVP soft state timeout.
If the ConfirmDataChannelStatus message is not recognized by the
RECEIVER, the RECEIVER ignores this message and will not send out an
acknowledgment message to the SENDER.
Due to the message loss problem, the SENDER may not be able to
receive the acknowledgment message.
ConfirmDataChannelStatus SHOULD be sent using LMP [<a href="./rfc4204" title=""Link Management Protocol (LMP)"">RFC4204</a>] reliable
transmission mechanisms. If, after the retry limit is reached, a
ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack
message is not received by the SENDER, the SENDER SHOULD terminate
the data channel confirmation procedure and SHOULD raise an alert to
the management plane.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
[<a id="ref-RFC4204">RFC4204</a>] describes how LMP messages between peers can be secured,
and these measures are equally applicable to the new messages defined
in this document.
The operation of the procedures described in this document does not
of itself constitute a security risk because it does not cause any
change in network state. It would be possible, if the messages were
intercepted or spoofed, to cause bogus alerts in the management
plane, and so the use of LMP security measures described in [<a href="./rfc4204" title=""Link Management Protocol (LMP)"">RFC4204</a>]
is RECOMMENDED.
Note that performing the procedures described in this document may
provide a useful additional security measure to verify that data
channels have not been illicitly modified.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. LMP Message Types</span>
IANA maintains the "Link Management Protocol (LMP)" registry, which
has a subregistry called "LMP Message Type". IANA has made the
following three new allocations from this registry.
<span class="grey">Li et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5818">RFC 5818</a> Data Channel Statuses and LMP April 2010</span>
Value Description
------ ---------------------------------
32 ConfirmDataChannelStatus
33 ConfirmDataChannelStatusAck
34 ConfirmDataChannelStatusNack
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. LMP Data Link Object Subobject</span>
IANA maintains the "Link Management Protocol (LMP)" registry, which
has a subregistry called "LMP Object Class name space and Class type
(C-Type)". This subregistry has an entry for the DATA_LINK object,
and there is a further embedded registry called "DATA_LINK Sub-object
Class name space". IANA has made the following allocation from this
embedded registry.
Value Description
------ ---------------------------------
9 Data Channel Status
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. LMP Error_Code Class Type</span>
IANA maintains the "Link Management Protocol (LMP)" registry, which
has a subregistry called "LMP Object Class name space and Class type
(C-Type)". This subregistry has an entry for the ERROR_CODE object.
IANA has allocated the following new value for an ERROR_CODE class
type.
C-Type Description Reference
------ ---------------------------- ---------
4 ConfirmDataChannelStatusNack [This RFC]
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgments</span>
The authors would like to thank Adrian Farrel, Dimitri Papadimitriou,
and Lou Berger for their useful comments.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<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-RFC4204">RFC4204</a>] Lang, J., Ed., "Link Management Protocol (LMP)",
<a href="./rfc4204">RFC 4204</a>, October 2005.
<span class="grey">Li et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5818">RFC 5818</a> Data Channel Statuses and LMP April 2010</span>
[<a id="ref-RFC5511">RFC5511</a>] Farrel, A., Ed., "Routing Backus-Naur Form (RBNF):
A Syntax Used to Form Encoding Rules in Various Routing
Protocol Specifications", <a href="./rfc5511">RFC 5511</a>, April 2009.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-RFC2205">RFC2205</a>] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and
S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", <a href="./rfc2205">RFC 2205</a>,
September 1997.
[<a id="ref-RFC3209">RFC3209</a>] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", <a href="./rfc3209">RFC 3209</a>, December 2001.
[<a id="ref-RFC3473">RFC3473</a>] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
<a href="./rfc3473">RFC 3473</a>, January 2003.
[<a id="ref-RFC4203">RFC4203</a>] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", <a href="./rfc4203">RFC 4203</a>, October 2005.
[<a id="ref-RFC4606">RFC4606</a>] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", <a href="./rfc4606">RFC 4606</a>, August 2006.
[<a id="ref-RFC5063">RFC5063</a>] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions
to GMPLS Resource Reservation Protocol (RSVP) Graceful
Restart", <a href="./rfc5063">RFC 5063</a>, October 2007.
[<a id="ref-RFC5307">RFC5307</a>] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", <a href="./rfc5307">RFC 5307</a>, October 2008.
Contributor's Address
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Shenzhen 518129 China
Phone: +86 755-289-72912
EMail: zhangfatai@huawei.com
<span class="grey">Li et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5818">RFC 5818</a> Data Channel Statuses and LMP April 2010</span>
Authors' Addresses
Dan Li
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Shenzhen 518129 China
Phone: +86 755-289-70230
EMail: danli@huawei.com
Huiying Xu
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Shenzhen 518129 China
Phone: +86 755-289-72910
EMail: xuhuiying@huawei.com
Snigdho C. Bardalai
Fujitsu Network Communications
2801 Telecom Parkway
Richardson, Texas 75082, USA
Phone: +1 972 479 2951
EMail: snigdho.bardalai@us.fujitsu.com
Julien Meuric
France Telecom Orange Labs
2, avenue Pierre Marzin
22307 Lannion Cedex, France
Phone: +33 2 96 05 28 28
EMail: julien.meuric@orange-ftgroup.com
Diego Caviglia
Ericsson
Via A. Negrone 1/A 16153
Genoa Italy
Phone: +39 010 600 3736
EMail: diego.caviglia@ericsson.com
Li et al. Standards Track [Page 15]
</pre>
|
