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
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
|
<pre>Internet Engineering Task Force (IETF) S. Mansfield, Ed.
Request for Comments: 5950 E. Gray, Ed.
Category: Informational Ericsson
ISSN: 2070-1721 K. Lam, Ed.
Alcatel-Lucent
September 2010
<span class="h1">Network Management Framework for MPLS-based Transport Networks</span>
Abstract
This document provides the network management framework for the
Transport Profile for Multi-Protocol Label Switching (MPLS-TP).
This framework relies on the management terminology from the ITU-T to
describe the management architecture that could be used for an MPLS-
TP management network.
The management of the MPLS-TP network could be based on multi-tiered
distributed management systems. This document provides a description
of the network and element management architectures that could be
applied and also describes heuristics associated with fault,
configuration, and performance aspects of the management system.
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
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). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <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/rfc5950">http://www.rfc-editor.org/info/rfc5950</a>.
<span class="grey">Mansfield, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5950">RFC 5950</a> NM Framework for MPLS-based Transport September 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-1.1">1.1</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Management Architecture . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.1">2.1</a>. Network Management Architecture . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. Element Management Architecture . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.3">2.3</a>. Standard Management Interfaces . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-2.4">2.4</a>. Management- and Control-Specific Terminology . . . . . . . <a href="#page-11">11</a>
<a href="#section-2.5">2.5</a>. Management Channel . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-3">3</a>. Fault Management . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-3.1">3.1</a>. Supervision . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-3.2">3.2</a>. Validation . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-3.3">3.3</a>. Alarm Handling . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4">4</a>. Configuration Management . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4.1">4.1</a>. LSP Ownership Handover . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-5">5</a>. Performance Management . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-6">6</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-7">7</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<span class="grey">Mansfield, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5950">RFC 5950</a> NM Framework for MPLS-based Transport September 2010</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document provides the network management framework for the
Transport Profile for Multi-Protocol Label Switching (MPLS-TP).
Requirements for network management in an MPLS-TP network are
documented in "Network Management Requirements for MPLS-based
Transport Networks" [<a href="#ref-3" title=""Network Management Requirements for MPLS-based Transport Networks"">3</a>], and this document explains how network
elements and networks that support MPLS-TP can be managed using
solutions that satisfy those requirements. The relationship between
Operations, Administration, and Maintenance (OAM), management, and
other framework documents is described in the MPLS-TP framework [<a href="#ref-4" title=""A Framework for MPLS in Transport Networks"">4</a>]
document.
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
This framework relies on the management terminology from the ITU-T to
describe the management architecture that could be used for an
MPLS-TP management network. The terminology listed below are taken
from/based on the definitions found in ITU-T G.7710 [<a href="#ref-6" title=""Common equipment management function requirements"">6</a>], ITU-T G.7712
[<a href="#ref-7" title=""Architecture and specification of data communication network"">7</a>], and ITU-T M.3013 [<a href="#ref-13" title=""Considerations for a telecommunication management network"">13</a>].
o Communication Channel (CCh): A logical channel between network
elements (NEs) that can be used in (for example) management plane
applications or control plane applications. For MPLS-TP, the
physical channel supporting the CCh is the MPLS-TP Management
Communication Channel (MCC).
o Data Communication Network (DCN): A network that supports Layer 1
(physical), Layer 2 (data-link), and Layer 3 (network)
functionality for distributed management communications related to
the management plane, for distributed signaling communications
related to the control plane, and other operations communications
(e.g., order-wire/voice communications, software downloads, etc.).
See ITU-T G.7712 [<a href="#ref-7" title=""Architecture and specification of data communication network"">7</a>].
o Equipment Management Function (EMF): The management functions
within an NE. See ITU-T G.7710 [<a href="#ref-6" title=""Common equipment management function requirements"">6</a>].
o Local Craft Terminal (LCT): An out-of-band device that connects to
an NE for management purposes. See ITU-T G.7710 [<a href="#ref-6" title=""Common equipment management function requirements"">6</a>].
<span class="grey">Mansfield, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5950">RFC 5950</a> NM Framework for MPLS-based Transport September 2010</span>
o Label Switched Path (LSP): An MPLS-TP LSP is an LSP that uses a
subset of the capabilities of an MPLS LSP in order to meet the
requirements of an MPLS transport network as described in the
MPLS-TP framework [<a href="#ref-4" title=""A Framework for MPLS in Transport Networks"">4</a>].
o Management Application Function (MAF): An application process that
participates in system management. See ITU-T G.7710 [<a href="#ref-6" title=""Common equipment management function requirements"">6</a>].
o Management Communication Channel (MCC): A CCh dedicated for
management plane communications. See ITU-T G.7712 [<a href="#ref-7" title=""Architecture and specification of data communication network"">7</a>].
o Message Communication Function (MCF): The communications process
that performs functions such as information interchange and relay.
See ITU-T M.3013 [<a href="#ref-13" title=""Considerations for a telecommunication management network"">13</a>].
o Management Communication Network (MCN): A DCN supporting
management plane communication is referred to as a Management
Communication Network (MCN). See ITU-T G.7712 [<a href="#ref-7" title=""Architecture and specification of data communication network"">7</a>].
o MPLS-TP NE: A network element (NE) that supports MPLS-TP
functions. Another term that is used for a network element is
node. In terms of this document, the term node is equivalent to
NE.
o MPLS-TP network: A network in which MPLS-TP NEs are deployed.
o Network Element Function (NEF): The set of functions necessary to
manage a network element. See ITU-T M.3010 [<a href="#ref-11" title=""Principles for a telecommunication management network"">11</a>].
o Operations, Administration, and Maintenance (OAM): For the MPLS-TP
effort the term OAM means the set of tools that consist of
"operation" activities that are undertaken to keep the network up
and running, "administration" activities that keep track of
resources in the network and how they are used, and "maintenance"
activities that facilitate repairs and upgrades. For a complete
expansion of the acronym, see "The OAM Acronym Soup" [<a href="#ref-15" title=""The OAM Acronym Soup"">15</a>].
o Operations System (OS): A system that performs the functions that
support processing of information related to operations,
administration, maintenance, and provisioning (OAM&P) (see "The
OAM Acronym Soup" [<a href="#ref-15" title=""The OAM Acronym Soup"">15</a>]) for the networks, including surveillance
and testing functions to support customer access maintenance. See
ITU-T M.3010 [<a href="#ref-11" title=""Principles for a telecommunication management network"">11</a>].
o Signaling Communication Network (SCN): A DCN supporting control
plane communication is referred to as a Signaling Communication
Network (SCN). See ITU-T G.7712 [<a href="#ref-7" title=""Architecture and specification of data communication network"">7</a>].
<span class="grey">Mansfield, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5950">RFC 5950</a> NM Framework for MPLS-based Transport September 2010</span>
o Signaling Communication Channel (SCC): A CCh dedicated for control
plane communications. The SCC may be used for GMPLS/ASON
signaling and/or other control plane messages (e.g., routing
messages). See ITU-T G.7712 [<a href="#ref-7" title=""Architecture and specification of data communication network"">7</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Management Architecture</span>
The management of the MPLS-TP network could be based on a multi-
tiered distributed management systems, for example as described in
ITU-T M.3010 [<a href="#ref-11" title=""Principles for a telecommunication management network"">11</a>] and ITU-T M.3060/Y.2401 [<a href="#ref-12" title=""Principles for the Management of Next Generation Networks"">12</a>]. Each tier provides a
predefined level of network management capabilities. The lowest tier
of this organization model includes the MPLS-TP network element that
provides the transport service and the Operations System (OS) at the
Element Management Level. The Management Application Function (MAF)
within the NEs and OSs provides the management support. The MAF at
each entity can include agents only, managers only, or both agents
and managers. The MAF that includes managers is capable of managing
an agent included in other MAF.
The management communication to peer NEs and/or OSs is provided via
the Message Communication Function (MCF) within each entity (e.g., NE
and OS). The user can access the management of the MPLS-TP transport
network via a Local Craft Terminal (LCT) attached to the NE or via a
Work Station (WS) attached to the OS.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Network Management Architecture</span>
A transport Management Network (MN) may consist of several transport-
technology-specific Management Networks. Management network
partitioning (Figure 1) below (based on ITU-T G.7710 [<a href="#ref-6" title=""Common equipment management function requirements"">6</a>]) shows the
management network partitioning. Notation used in G.7710 for a
transport-technology-specific MN is x.MN, where x is the transport-
specific technology. An MPLS-TP-specific MN is abbreviated as MT.MN.
Where there is no ambiguity, we will use "MN" for an MPLS-TP-specific
MN. In the figure below, O.MSN is equivalent to an OTN management
Subnetwork.
<span class="grey">Mansfield, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5950">RFC 5950</a> NM Framework for MPLS-based Transport September 2010</span>
______________________________ _________________________________
|.-------.-------.----.-------.||.--------.--------.----.--------.|
|: : : : :||: : : : :|
|:O.MSN-1:O.MSN-2: .. :O.MSN-n:||:MT.MSN-1:MT.MSN-2: .. :MT.MSN-n:|
|: : : : :||: : : : :|
'-============================-''-===============================-'
_______________________________
|.-------.-------.-----.-------.|
|: : : : :|
|:x.MSN-1:x.MSN-2: ... :x.MSN-n:|
|: : : : :|
'-=============================-'
Management Network Partitioning
Figure 1
The management of the MPLS-TP network is separable from the
management of the other technology-specific networks, and it operates
independently of any particular client- or server-layer management
plane.
An MPLS-TP Management Network (MT.MN) could be partitioned into
MPLS-TP Management SubNetworks ("MT.MSN" or "MPLS-TP MSN", or just
"MSN" where usage is unambiguous) for consideration of scalability
(e.g., geographic or load balancing) or administration (e.g.,
operation or ownership).
The MPLS-TP MSN could be connected to other parts of the MN through
one or more LCTs and/or OSs. The Message Communication Function
(MCF) of an MPLS-TP NE initiates/terminates, routes, or otherwise
processes management messages over CChs or via an external interface.
Multiple addressable MPLS-TP NEs could be present at a single
physical location (i.e., site or office). The inter-site
communications link between the MPLS-TP NEs will normally be provided
by the CChs. Within a particular site, the NEs could communicate via
an intra-site CCh or via a LAN.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Element Management Architecture</span>
The Equipment Management Function (EMF) of an MPLS-TP NE provides the
means through which a management system manages the NE.
The EMF interacts with the NE's transport functions by exchanging
Management Information (MI) across the Management Point (MP)
Reference Points. The EMF may contain a number of functions that
<span class="grey">Mansfield, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5950">RFC 5950</a> NM Framework for MPLS-based Transport September 2010</span>
provide a data reduction mechanism on the information received across
the MP Reference Points.
The EMF includes functions such as Date and Time, FCAPS (Fault,
Configuration, Accounting, Performance, and Security) management, and
Control Plane functions. The EMF provides event message processing,
data storage, and logging. The management Agent, a component of the
EMF, converts internal management information (MI signals) into
Management Application messages and vice versa. The Agent responds
to Management Application messages from the Message Communication
Function (MCF) by performing the appropriate operations on (for
example) the Managed Objects in a Management Information Base (MIB),
as necessary. The MCF contains communications functions related to
the world outside of the NE (i.e., Date and Time source, Management
Plane, Control Plane, Local Craft Terminal, and Local Alarms).
The Date and Time functions keep track of the NE's date/time, which
is used by the FCAPS management functions to e.g., time stamp event
reports.
Below are diagrams that illustrate the components of the Equipment
Management Function (EMF) of a Network Element (NE). The high-level
decomposition of the Network Element Function (NEF) picture
(Figure 2) provides the breakdown of the NEF, then the EMF picture
(Figure 3) provides the details of Equipment Management Function, and
finally the Message Communication Function (MCF) picture (Figure 4)
details the MCF.
<span class="grey">Mansfield, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5950">RFC 5950</a> NM Framework for MPLS-based Transport September 2010</span>
____________________________________________________
| Network Element Function (NEF) |
| _________________________________________ |
|| | |
|| Transport Plane Atomic Functions | |
||_________________________________________| |
| | |
| | Management |
| | Information |
| ___________________|_________________ |
| | (from date/time)<-----------+ |
| | Equipment | | |
| | Management (to/from management)<--------+ | |
| | Function | | | |
| | (EMF) (to/from control)<-----+ | | |
| | | | | | |
| | (to local alarm)---+ | | | |
| |_____________________________________| | | | | |
| | | | | |
| +--------------------------------------+ | | | |
| | +---------------------------------------+ | | |
| | | +----------------------------------------+ | |
| | | | +-----------------------------------------+ |external
| | | | | Date & Time _________________ |time
| | | | | Interface | Message | |source
| | | | +-------------- Communication <-----------------------
| | | | | Function (MCF) | |
| | | | Management | | |management
| | | +----------------> | |plane
| | | Plane Interface <---------------------->
| | | | | |local
| | | | | |craft
| | | Control Plane | | |terminal
| | +------------------> <---------------------->
| | Interface | | |control
| | | | |plane
| | Local Alarm | <---------------------->
| +--------------------> | |
| Interface | | |to local
| | | |alarms
| |_________________--------------------->
|____________________________________________________|
High-Level Decomposition of NEF
Figure 2
<span class="grey">Mansfield, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5950">RFC 5950</a> NM Framework for MPLS-based Transport September 2010</span>
______________________________________________________
| _______________________________________ |
| Equipment | Management Application ||
| Management | Function (MAF) ||
| Function | _________________ ||
| (EMF) || | __________________||
| ___________||_______________ | | ||
| | | | | Date & Time ||
| | Date & Time Functions | | | Interface ||<-- 1
| |____________________________| | |__________________||
| ___________||_______________ | __________________||
| | | | | ||
| | Fault Management | | | Management ||
| |____________________________| | | Plane Interface ||<-> 2
| ___________||_______________ | |__________________||
| | | | ||
| | Configuration Management | | __________________||
| |____________________________| | | ||
| ___________||_______________ | | Control ||
| | | | | Plane Interface ||<-> 3
| | Account Management | | |__________________||
| |____________________________| | ||
| ___________||_______________ | ||
| | | | ||
| | Performance Management | | ||
| |____________________________| | ||
| ___________||_______________ | ||
| | | | ||
| | Security Management | | ||
| |____________________________| | ||
| ___________||_______________ | ||
| | | | ||
| | Control Plane Function | | ||
| |____________________________| | ||
| || | __________________||
| || | | ||
| || | | Local Alarm ||
| +----->| Agent | | Interface ||--> 4
| v ||_________________| |__________________||
| .-===-. |_______________________________________||
| | MIB | |
| `-._.-' |
|______________________________________________________|
Equipment Management Function
Figure 3
<span class="grey">Mansfield, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5950">RFC 5950</a> NM Framework for MPLS-based Transport September 2010</span>
_________________
| |
| Message |
| Communication |
| Function (MCF) |
| _______________ |
Date & Time || || external
1 <--------------|| Date & Time ||<--------------
Information || Communication || time source
||_______________||
| |
| _______________ |
Management || || management
Plane || Management || plane
2 <------------->|| Plane ||<------------->
Information || Communication || (e.g. - EMS,
||_______________|| peer NE)
| |
| _______________ | control
Control Plane || || plane
3 <------------->|| Control Plane ||<------------->
Information || Communication || (e.g. - EMS,
||_______________|| peer NE)
| : |
| : | local craft
| : | terminal
| : |<------------->
| _______________ |
Local Alarm || || to local
4 -------------->|| Local Alarm ||-------------->
Information || Communication || alarms...
||_______________||
|_________________|
Message Communication Function
Figure 4
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Standard Management Interfaces</span>
The "Network Management Requirements for MPLS-based Transport
Networks" document [<a href="#ref-3" title=""Network Management Requirements for MPLS-based Transport Networks"">3</a>] places no restriction on which management
interface is to be used for managing an MPLS-TP network. It is
possible to provision and manage an end-to-end connection across a
network where some segments are created/managed/deleted, for example
by NETCONF or SNMP and other segments by CORBA interfaces. Use of
any network management interface for one management-related purpose
does not preclude use of another network management interface for
<span class="grey">Mansfield, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5950">RFC 5950</a> NM Framework for MPLS-based Transport September 2010</span>
other management-related purposes, or the same purpose at another
time. The protocol(s) to be supported are at the discretion of the
operator.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Management- and Control-Specific Terminology</span>
Data Communication Network (DCN) is the common term for the network
used to transport Management and Signaling information between:
management systems and network elements, management systems to other
management systems, and networks elements to other network elements.
The Management Communications Network (MCN) is the part of the DCN
that supports the transport of Management information for the
Management Plane. The Signaling Communications Network (SCN) is the
part of the DCN that supports transport of signaling information for
the Control Plane. As shown in , the communication channel
terminology picture (Figure 5) each technology has its own
terminology that is used for the channels that support the transfer
of management and control plane information. For MPLS-TP, the
management plane uses the Management Communication Channel (MCC), and
the control plane uses the Signaling Communication Channel (SCC).
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Management Channel</span>
The Communication Channel (CCh) provides a logical channel between
NEs for transferring Management and/or Signaling information. Note
that some technologies provide separate communication channels for
Management (MCC) and Signaling (SCC).
MPLS-TP NEs communicate via the DCN. The DCN connects NEs with
management systems, NEs with NEs, and management systems with
management systems.
<span class="grey">Mansfield, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5950">RFC 5950</a> NM Framework for MPLS-based Transport September 2010</span>
Common Terminology ____
__________ __________ | |
| | | | /->| NE | \ ____
|Management| |Operations| / |____| \ | |
|Station | <---> |System | |(CCh) | NE |
|__________| |__________| \ _|__ / |____|
\->| | /
| NE |
|____|
Network Elements use a Communication
Channel (CCh) for Transport of Information
Management Terminology ____
__________ __________ | |
| | | | /->| NE | \ ____
|Management| |Operations| / |____| \ | |
|Station | <---> |System | |(MCC) | NE |
|__________| |__________| \ _|__ / |____|
\->| | /
| NE |
|____|
Network Elements use a Management
Communication Channel (MCC) for Transport
of Management Information
Control Terminology ____
__________ __________ | |
| | | | /->| NE | \ ____
|Management| |Operations| / |____| \ | |
|Station | <---> |System | |(SCC) | NE |
|__________| |__________| \ _|__ / |____|
\->| | /
| NE |
|____|
Network Elements use a Control/Signaling
Communication Channel (SCC) for Transport
of Signaling Information
Communication Channel Terminology
Figure 5
<span class="grey">Mansfield, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5950">RFC 5950</a> NM Framework for MPLS-based Transport September 2010</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Fault Management</span>
A fault is the inability of a function to perform a required action.
This does not include an inability due to preventive maintenance,
lack of external resources, or planned actions. Fault management
provides the mechanisms to detect, verify, isolate, notify, and
recover from the fault.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Supervision</span>
ITU-T G.7710 [<a href="#ref-6" title=""Common equipment management function requirements"">6</a>] lists five basic categories of supervision that
provide the functionality necessary to detect, verify, and notify a
fault. The categories are: Transmission Supervision, Quality of
Service Supervision, Processing Supervision, Hardware Supervision,
and Environment Supervision. Each of the categories provides a set
of recommendations to ensure that the fault management process is
fulfilled.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Validation</span>
ITU-T G.7710 [<a href="#ref-6" title=""Common equipment management function requirements"">6</a>] describes a fault cause as a limited interruption of
the required function. It is not reasonable for every fault cause to
be reported to maintenance personnel. The validation process is used
to turn fault causes (events) into failures (alarms).
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Alarm Handling</span>
Within an element management system, it is important to consider
mechanisms to support severity assignment, alarm reporting control,
and logging.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Configuration Management</span>
Configuration management provides the mechanisms to:
o provision the MPLS-TP services
o set up security for the MPLS-TP services and MPLS-TP network
elements
o provide the destination for fault notifications and performance
parameters
o configure and control OAM
Also associated with configuration management are hardware and
software provisioning and inventory reporting.
<span class="grey">Mansfield, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5950">RFC 5950</a> NM Framework for MPLS-based Transport September 2010</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. LSP Ownership Handover</span>
MPLS-TP networks can be managed not only by Network Management
Systems (i.e., Management Plane (MP)), but also by Control Plane (CP)
protocols. The utilization of the control plane is not a mandatory
requirement (see MPLS-TP Requirements [<a href="#ref-2" title=""Requirements of an MPLS Transport Profile"">2</a>]), but it is often used by
network operators in order to make network configuration and Label
Switched Path (LSP) recovery both faster and simpler.
In networks where both CP and MP are provided, an LSP could be
created by either (CP or MP). The entity creating an LSP owns the
data plane resources comprising that LSP. Only the owner of an LSP
is typically able to modify/delete it. This results in a need for
interaction between the MP and CP to allow either to manage all the
resources of a network.
Network operators might prefer to have full control of the network
resources during the set-up phase and then allow the network to be
automatically maintained by the Control Plane. This can be achieved
by creating LSPs via the Management Plane and subsequently
transferring LSP ownership to the Control Plane. This is referred to
as "ownership handover" <a href="./rfc5493">RFC 5493</a> [<a href="#ref-10" title=""Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network"">10</a>]. MP to CP ownership handover
is then considered a requirement where a Control Plane is in use that
supports it. The converse (CP to MP ownership handover) is a feature
that is recommended -- but not required -- for (G)MPLS networks
because it has only minor applications (for example, moving LSPs from
one path to another as a maintenance operation).
The LSP handover procedure has already been standardized for GMPLS
networks, where the signaling protocol used is RSVP-TE (<a href="./rfc3209">RFC 3209</a>
[<a href="#ref-1" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">1</a>]). The utilization of RSVP-TE enhancements are defined in [<a href="#ref-5" title=""RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network"">5</a>].
MP and CP interworking also includes the exchange of information that
is either requested by the MP, or a notification by the CP as a
consequence of a request from the MP or an automatic action (for
example, a failure occurs or an operation is performed). The CP is
asked to notify the MP in a reliable manner about the status of the
operations it performs and to provide a mechanism to monitor the
status of Control Plane objects (e.g., TE Link status, available
resources), and to log operations related to Control Plane LSP.
Logging is one of the most critical aspects because the MP always
needs to have an accurate history and status of each LSP and all Data
Plane resources involved in it.
<span class="grey">Mansfield, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5950">RFC 5950</a> NM Framework for MPLS-based Transport September 2010</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Performance Management</span>
Performance statistics could overwhelm a Management Network, so it is
important to provide flexible instrumentation that enables control
over the amount of performance data to be collected. Mechanisms for
limiting the quantity of information collected are well known and
deployed in IETF standards (see <a href="./rfc2819">RFC 2819</a> (RMON) [<a href="#ref-8" title=""Remote Network Monitoring Management Information Base"">8</a>] and <a href="./rfc4502">RFC 4502</a>
(RMON2) [<a href="#ref-9" title=""Remote Network Monitoring Management Information Base Version 2"">9</a>]). The details of the performance data collected
(including loss and delay measurement data) are found in the "Network
Management Requirements for MPLS-based Transport Networks" document
[<a href="#ref-3" title=""Network Management Requirements for MPLS-based Transport Networks"">3</a>].
A distinction is made between performance data that is collected on-
demand and data that is collected proactively. The definitions of
on-demand and proactive measurement are provided for OAM in the
"Network Management Requirements for MPLS-based Transport Networks"
document [<a href="#ref-3" title=""Network Management Requirements for MPLS-based Transport Networks"">3</a>].
On-demand measurement provides the operator with the ability to do
performance measurement for maintenance purpose, such as diagnosis or
to provide detailed verification of proactive measurement. It is
used typically on specific LSP service instances for a limited time,
thus limiting its impact on network performance under normal
operations. Therefore, on-demand measurement does not result in
scaling issues.
Proactive measurement is used continuously over time after being
configured with periodicity and storage information. Data collected
from proactive measurement are usually used for verifying the
performance of the service. Proactive performance monitoring has the
potential to overwhelm both the process of collecting performance
data at a network element (for some arbitrary number of service
instances traversing the NE), and the process of reporting this
information to the OS. As a consequence of these considerations,
operators would typically limit the services to which proactive
performance measurement would be applied to a very selective subset
of the services being provided and would limit the reporting of this
information to statistical summaries (as opposed to raw or detailed
performance statistics).
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Acknowledgements</span>
The authors/editors gratefully acknowledge the thoughtful review,
comments and explanations provided by Diego Caviglia, Bernd Zeuner
and Dan Romascanu.
<span class="grey">Mansfield, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5950">RFC 5950</a> NM Framework for MPLS-based Transport September 2010</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
The ability for the authorized network operator to access EMF
interfaces (<a href="#section-2.3">Section 2.3</a>) when needed is critical to proper operation.
Therefore, the EMF interfaces need to be protected from denial-of-
service conditions or attack. The EMF interfaces that use or access
private information should be protected from eavesdropping, mis-
configuration, and/or mal-configuration by unauthorized network
elements, systems, or users.
Performance of diagnostic functions and path characterization
involves extracting a significant amount of information about network
construction that the network operator considers private.
<a href="#section-4.3">Section 4.3</a> of the "Security Framework for MPLS and GMPLS Networks"
document [<a href="#ref-14" title=""Security Framework for MPLS and GMPLS Networks"">14</a>] provides a description of the attacks on the Operation
and Management Plane and also discusses the background necessary to
understand security practices in Internet Service Provider
environments. The security practices described are applicable to
MPLS-TP environments.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-1">1</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-2">2</a>] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
S. Ueno, "Requirements of an MPLS Transport Profile", <a href="./rfc5654">RFC 5654</a>,
September 2009.
[<a id="ref-3">3</a>] Lam, K., Mansfield, S., and E. Gray, "Network Management
Requirements for MPLS-based Transport Networks", <a href="./rfc5951">RFC 5951</a>,
September 2010.
[<a id="ref-4">4</a>] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A
Framework for MPLS in Transport Networks", <a href="./rfc5921">RFC 5921</a>, July 2010.
[<a id="ref-5">5</a>] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S.
Bardalai, "RSVP-TE Signaling Extension for LSP Handover from
the Management Plane to the Control Plane in a GMPLS-Enabled
Transport Network", <a href="./rfc5852">RFC 5852</a>, April 2010.
[<a id="ref-6">6</a>] International Telecommunication Union, "Common equipment
management function requirements", ITU-T Recommendation G.7710/
Y.1701, July 2007.
<span class="grey">Mansfield, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5950">RFC 5950</a> NM Framework for MPLS-based Transport September 2010</span>
[<a id="ref-7">7</a>] International Telecommunication Union, "Architecture and
specification of data communication network",
ITU-T Recommendation G.7712/Y.1703, June 2008.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-8">8</a>] Waldbusser, S., "Remote Network Monitoring Management
Information Base", STD 59, <a href="./rfc2819">RFC 2819</a>, May 2000.
[<a id="ref-9">9</a>] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2", <a href="./rfc4502">RFC 4502</a>, May 2006.
[<a id="ref-10">10</a>] Caviglia, D., Bramanti, D., Li, D., and D. McDysan,
"Requirements for the Conversion between Permanent Connections
and Switched Connections in a Generalized Multiprotocol Label
Switching (GMPLS) Network", <a href="./rfc5493">RFC 5493</a>, April 2009.
[<a id="ref-11">11</a>] International Telecommunication Union, "Principles for a
telecommunication management network", ITU-T Recommendation
M.3010, April 2005.
[<a id="ref-12">12</a>] International Telecommunication Union, "Principles for the
Management of Next Generation Networks", ITU-T Recommendation
M.3060/Y.2401, March 2006.
[<a id="ref-13">13</a>] International Telecommunication Union, "Considerations for a
telecommunication management network", ITU-T Recommendation
M.3013, February 2000.
[<a id="ref-14">14</a>] Fang, L., "Security Framework for MPLS and GMPLS Networks",
<a href="./rfc5920">RFC 5920</a>, July 2010.
[<a id="ref-15">15</a>] Andersson, L., Helvoort, H., Bonica, R., Romascanu, D., and S.
Mansfield, ""The OAM Acronym Soup"", Work in progress,
June 2010.
<span class="grey">Mansfield, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5950">RFC 5950</a> NM Framework for MPLS-based Transport September 2010</span>
Authors' Addresses
Scott Mansfield (editor)
Ericsson
300 Holger Way
San Jose, CA 95134
US
Phone: +1 724 931 9316
Email: scott.mansfield@ericsson.com
Eric Gray (editor)
Ericsson
900 Chelmsford Street
Lowell, MA 01851
US
Phone: +1 978 275 7470
Email: eric.gray@ericsson.com
Hing-Kam Lam (editor)
Alcatel-Lucent
600-700 Mountain Ave
Murray Hill, NJ 07974
US
Phone: +1 908 582 0672
Email: Kam.Lam@alcatel-lucent.com
Mansfield, et al. Informational [Page 18]
</pre>
|
