idnits 2.17.1 draft-ietf-mpls-mgmt-overview-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 29 longer pages, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 596 has weird spacing: '...rfTable mpl...' == Line 968 has weird spacing: '...XCTable mpls...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2003) is 7528 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2401' is defined on line 1431, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Thomas D. Nadeau 2 Internet Draft Cisco Systems, Inc. 3 Category: Informational 4 Expires: March 2004 Cheenu Srinivasan 5 Bloomberg L.P. 7 Adrian Farrel 8 Old Dog Consulting 10 September 2003 12 Multiprotocol Label Switching (MPLS) Management Overview 14 draft-ietf-mpls-mgmt-overview-09.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full 19 conformance with all provisions of Section 10 of RFC 2026 20 [RFC2026]. 22 Internet-Drafts are working documents of the Internet 23 Engineering Task Force (IETF), its areas, and its working 24 groups. Note that other groups may also distribute working 25 documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of 28 six months and may be updated, replaced, or obsoleted by 29 other documents at any time. It is inappropriate to use 30 Internet-Drafts as reference material or to cite them other 31 than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be 37 accessed at http://www.ietf.org/shadow.html. 39 Abstract 41 A range of Management Information Base (MIB) modules has 42 been developed to help model and manage the various aspects 43 of Multiprotocol Label Switching (MPLS) networks. These MIB 44 modules are defined in separate documents that focus on the 45 specific areas of responsibility of the modules that they 46 describe. 48 This document describes the management architecture for MPLS 49 and indicates the inter-relationships between the different 50 MIB modules used for MPLS network management. 52 Table of Contents 53 1. Introduction 3 54 2. Terminology 3 55 3. The SNMP Management Framework 4 56 4. An Introduction to the MPLS Working Group MIB Modules 4 57 4.1. Structure of the MPLS MIB OID Tree 5 58 4.2. MPLS-TC-STD-MIB 5 59 4.3. MPLS-LSR-STD-MIB 5 60 4.4. MPLS-LDP-STD-MIB 6 61 4.5. MPLS-LDP-GENERIC-STD-MIB 6 62 4.6. MPLS-LDP-ATM-STD-MIB 6 63 4.7. MPLS-LDP-FRAME-RELAY-STD-MIB 7 64 4.8. MPLS-TE-STD-MIB 7 65 4.9. MPLS-FTN-STD-MIB 7 66 4.10. TE-LINK-STD-MIB 7 67 4.11. MIB Module Interdependencies 8 68 4.12. Dependencies on External MIB Modules 8 69 5. Tables, Scalars and Notifications in MPLS-LSR-STD-MIB 9 70 5.1. Tables 9 71 5.2. Scalars 10 72 5.3. Indexing 10 73 5.4. Notifications 11 74 5.5. Dependencies Between MIB Module Tables 11 75 6. Tables, Scalars and Notifications in the LDP MIB 12 76 6.1. MIB Modules 12 77 6.2. Tables 12 78 6.3. Scalars 13 79 6.4. Notifications 14 80 6.5. Dependencies Between MIB Module Tables 14 81 7. Tables, Scalars and Notifications in MPLS-TE-STD-MIB 15 82 7.1. Tables 15 83 7.2. Scalars 16 84 7.3. Notifications 16 85 7.4. Dependencies Between MIB Module Tables 16 86 8. Tables, Scalars and Notifications in MPLS-FTN-STD-MIB 17 87 8.1. Tables 17 88 8.2. Scalars 17 89 8.3. Notifications 17 90 8.4. Dependencies Between MIB Module Tables 17 91 9. Tables and Objects in TE-LINK-STD-MIB 17 92 9.1. Tables 17 93 9.2. Scalars 18 94 9.3. Notifications 18 95 9.4. Dependencies Between MIB Module Tables 18 96 10. Table Dependencies Between MPLS MIB Modules 19 97 11. A Note on Interfaces 19 98 11.1. MPLS Tunnels as Interfaces 19 99 11.2. Application of the Interfaces Group to TE Links 20 100 11.3. References to Interface MIB Objects from MPLS MIB Modules 21 101 12. Management Options 22 102 13. Related IETF MIB Modules 23 103 13.1. PWE3 Working Group MIB Modules 23 104 13.2. PPVPN Working Group MIB Modules 23 105 13.2.1. PPVPN-MPLS-VPN-STD-MIB 23 106 13.3. CCAMP Working Group MIB Modules 24 107 14. Traffic Engineering Working Group TE MIB 24 108 14.1. Choosing Between TE MIB Modules 24 110 15. Security Considerations 25 111 16. Acknowledgements 26 112 17. Intellectual Property Consideration 26 113 18. Normative References 26 114 19. Informative References 27 115 20. Authors' Addresses 29 116 21. Full Copyright Statement 29 118 1. Introduction 120 This document describes the Management Architecture for Multi- 121 Protocol Label Switching (MPLS) [RFC3031]. In particular, 122 it describes how the managed objects defined in various 123 MPLS related Management Information Base (MIB) documents 124 model different aspects of MPLS. Furthermore, this document 125 explains the interactions and dependencies between each of 126 these MIB modules. 128 For additional information, this document also includes a 129 brief note on MIB modules produced by the Pseudo Wire 130 Emulation Edge to Edge (PWE3), Provider Provisioned Virtual 131 Private Network (PPVPN), Common Control and Measurement 132 Plane (CCAMP), and Internet Traffic Engineering (TEWG) 133 working groups. 135 The document begins with a brief outline of the SNMP 136 framework. This is not intended to be a complete reference 137 on SNMP, but is provided to give context to the rest of the 138 document and to indicate reference material for readers that 139 need to know more about SNMP. 141 This document does not propose any additions to the MPLS MIB 142 framework, nor define any standards for the Internet 143 community. It is an informational document. In all cases, 144 the reader is advised to turn to the document that defines 145 the MIB module in question for further information. 147 Comments should be made directly to the MPLS mailing list 148 at mpls@uu.net. 150 2. Terminology 152 This document uses terminology from the MPLS architecture 153 document [RFC3031] and the following MPLS related MIB 154 modules: MPLS TC MIB [TCMIB], MPLS LSR MIB [LSRMIB], 155 MPLS TE MIB [TEMIB], MPLS LDP MIB [LDPMIB], 156 MPLS FTN MIB [FTNMIB], TE LINK MIB [TELMIB], and 157 PPVPN MPLS VPN MIB [VPNMIB]. 159 Throughout this document hyphenated MIB names (such as MPLS- 160 TE-STD-MIB) should be taken to refer to specific MIB modules. 161 Non-hyphenated MIB names (such as MPLS LDP MIB) indicate 162 MIB documents. 164 3. The SNMP Management Framework 166 For a detailed overview of the documents that describe the current 167 Internet-Standard Management Framework, please refer to section 7 of 168 RFC 3410 [RFC3410]. 170 Managed objects are accessed via a virtual information store, termed 171 the Management Information Base or MIB. MIB objects are generally 172 accessed through the Simple Network Management Protocol (SNMP). 173 Objects in the MIB are defined using the mechanisms defined in the 174 Structure of Management Information (SMI). This document specifies a 175 MIB module that is compliant to the SMIv2, which is described in 176 STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, 177 RFC 2580 [RFC2580]. 179 4. An Introduction to the MPLS Working Group MIB Modules 181 This section addresses the MIB documents produced by the 182 MPLS working group, namely MPLS TC MIB, MPLS LSR MIB, MPLS 183 TE MIB, MPLS LDP MIB, MPLS FTN MIB, and TE LINK MIB. The 184 rest of this section briefly describes the following: 186 - the MPLS Object Identifier (OID) tree structure and the 187 position of different MPLS related MIB modules on this tree; 189 - the purpose of each of the MIB modules within the MIB 190 documents, what it can be used for, and how it relates 191 to the other MIB modules. 193 Note that each MIB document contains one or more compliance 194 statements for the modules and objects that it defines. The 195 support for the different MIB modules and objects is, therefore 196 beyond the scope of this document although some recommendations 197 are included in the sections that follow. 199 4.1. Structure of the MPLS MIB OID Tree 201 The MPLS MIB OID tree has the following structure. 203 transmission -- RFC 2578 [RFC2578] 204 | 205 +- mplsStdMIB -- MPLS-TC-STD-MIB 206 | | 207 | +- mplsTCStdMIB -- MPLS-TC-STD-MIB 208 | | 209 | +- mplsLsrStdMIB -- MPLS-LSR-STD-MIB 210 | | 211 | +- mplsTeStdMIB -- MPLS-TE-STD-MIB 212 | | 213 | +- mplsLdpStdMIB -- MPLS-LDP-STD-MIB 214 | | 215 | +- mplsLdpAtmStdMIB -- MPLS-LDP-ATM-STD-MIB 216 | | 217 | +- mplsLdpFrameRelayStdMIB -- MPLS-LDP-FRAME-RELAY-STD-MIB 218 | | 219 | +- mplsLdpGenericStdMIB -- MPLS-LDP-GENERIC-STD-MIB 220 | | 221 | +- mplsFTNStdMIB -- MPLS-FTN-STD-MIB 222 | 223 +- teLinkStdMIB -- TE-LINK-STD-MIB 225 Note: The OIDs for MIB modules are assigned and managed by IANA. 226 They can be found in the referenced MIB documents. 228 4.2. MPLS-TC-STD-MIB 230 MPLS-TC-STD-MIB defines textual conventions [RFC2579] that may be 231 common to MPLS related MIB modules. These conventions allow 232 multiple MIB modules to use the same syntax and format for a 233 concept that is shared between the MIB modules. 235 For example, labels are a central part of MPLS and need to 236 be presented in many of the MIB modules. The textual 237 convention for representing an MPLS label is defined in 238 MPLS-TC-STD-MIB. 240 All of the other MPLS MIB modules import textual conventions 241 from this MIB module. 243 4.3. MPLS-LSR-STD-MIB 245 MPLS-LSR-STD-MIB describes managed objects for modeling an MPLS 246 Label Switching Router (LSR). This puts it at the heart of 247 the management architecture for MPLS. 249 This MIB module is used to model and manage the basic label 250 switching behavior of an MPLS LSR. It represents the label 251 forwarding information base (LFIB) of the LSR and provides 252 a view of the LSPs that are being switched by the LSR in 253 question. 255 Since basic MPLS label switching is common to all MPLS 256 applications, this MIB module is referenced by many of the 257 other MPLS MIB modules. 259 In general, MPLS-LSR-STD-MIB provides a model of incoming 260 labels on MPLS-enabled interfaces being mapped to outgoing 261 labels on MPLS-enabled interfaces via a conceptual object 262 called an MPLS cross-connect. MPLS cross-connect entries 263 and their properties are represented in MPLS-LSR-STD-MIB and 264 are typically referenced by other MIB modules in order to 265 refer to the underlying MPLS LSP. 267 For example, MPLS-TE-STD-MIB models traffic engineered tunnels. 268 These tunnels map to one or more underlying MPLS LSPs. 269 MPLS-TE-STD-MIB refers to the underlying LSPs by pointing to 270 cross-connect entries in MPLS-LSR-STD-MIB. 272 4.4. MPLS-LDP-STD-MIB 274 MPLS-LDP-STD-MIB describes managed objects used to model and 275 manage the MPLS Label Distribution Protocol (LDP) 276 [RFC3036]. LDP is one of the MPLS protocols used to 277 distribute labels and establish LSPs. 279 This MIB module contains objects common to all LDP 280 implementations. For an LDP implementation that provides 281 standard MIB support, this MIB module provides the core 282 set of objects that are needed along with one or more of 283 the other LDP MIB modules from the following sections. 285 4.5. MPLS-LDP-GENERIC-STD-MIB 287 This MIB module provides objects for managing the LDP Per 288 Platform Label Space and is typically implemented along 289 with the MPLS-LDP-STD-MIB module. This MIB Module contains 290 tables for configuring MPLS Generic Label Ranges. Although 291 the LDP Specification does not provide a way for configuring 292 Label Ranges for Generic Labels, the MIB module does provide 293 a way to reserve a range of generic labels because this was 294 thought to be useful by the working group. 296 4.6. MPLS-LDP-ATM-STD-MIB 298 This MIB module is typically supported along with 299 MPLS-LDP-STD-MIB by LDP implementations if LDP uses ATM as 300 the Layer 2 medium. Tables in this MIB module allow for 301 configuring LDP to use ATM. 303 4.7. MPLS-LDP-FRAME-RELAY-STD-MIB 305 This MIB module is typically supported along with 306 MPLS-LDP-STD-MIB by LDP implementations if LDP uses Frame Relay 307 as the Layer 2 medium. Tables in this MIB module allow for 308 configuration of LDP to use Frame Relay. 310 4.8. MPLS-TE-STD-MIB 312 MPLS-TE-STD-MIB describes managed objects that are used to 313 model and manage MPLS Traffic Engineered (TE) Tunnels. 315 This MIB module is based around a table that represents TE 316 tunnels that either originate from, traverse via or 317 terminate on the LSR in question. The MIB module provides 318 configuration and statistics objects needed for TE tunnels. 320 4.9. MPLS-FTN-STD-MIB 322 MPLS-FTN-STD-MIB describes managed objects that are used to 323 model and manage the MPLS FEC-to-NHLFE (FTN) mappings that 324 take place at an ingress Label Edge Router (LER). 326 An LER is an LSR placed at the edge of an MPLS domain, and 327 passes traffic into and out of the MPLS domain. An ingress 328 LER is responsible for classifying data and assigning it to 329 a suitable LSP or tunnel. 331 This classification is done using Forwarding Equivalence 332 Classes (FECs) that define the common attributes of data 333 (usually packets) that will be treated in the same way. 334 Once data has been classified it can be handed off to an 335 LSP or tunnel through the Next Hop Label Forwarding Entry 336 (NHLFE). 338 In the case of an IP-to-MPLS mapping, the FEC objects 339 describe IP 6-tuples representing source and destination 340 address ranges, source and destination port ranges, IPv4 341 Protocol field or IPv6 next-header field and the DiffServ 342 Code Point (DSCP). 344 4.10. TE-LINK-STD-MIB 346 TE-LINK-STD-MIB describes managed objects that are used to model 347 and manage TE links, including bundled links, in an MPLS network. 349 The TE link feature is designed to aggregate one or more similar 350 data channels or TE links between a pair of LSRs. A TE link 351 is a sub-interface capable of carrying traffic engineered MPLS 352 traffic. 354 A bundled link is a sub-interface that bonds the traffic of 355 a group of one or more TE links. 357 4.11. MIB Module Interdependencies 359 This section provides an overview of the relationship 360 between the MPLS MIB modules described above. More details 361 of these relationships are given below once the MIB modules 362 have been discussed in more detail. 364 The arrows in the following diagram show a 'depends on' relationship. 365 A relationship "MIB module A depends on MIB module B" means that MIB 366 module A uses a an object, object identifier, or textual convention 367 defined in MIB module B, or that MIB module A contains a pointer 368 (index or RowPointer) to an object in MIB module B. 370 +-------> MPLS-TC-STD-MIB 371 | ^ 372 | | 373 | MPLS-LSR-STD-MIB <------------------+ 374 | | 375 +<----------------------- MPLS-LDP-STD-MIB -->+ 376 | ^ | 377 | | | 378 +<-- MPLS-LDP-GENERIC-STD-MIB ------>+ | 379 | | | 380 +<-- MPLS-LDP-ATM-STD-MIB ---------->+ | 381 | | | 382 +<-- MPLS-LDP-FRAME-RELAY-STD-MIB -->+ | 383 | | 384 +<------- MPLS-TE-STD-MIB ------------------->+ 385 | ^ | 386 | | | 387 +<------- MPLS-FTN-STD-MIB ------------------>+ 389 Thus: 391 - All the MPLS MIB modules depend on MPLS-TC-STD-MIB. 393 - MPLS-LDP-STD-MIB, MPLS-TE-STD-MIB and MPLS-FTN-STD-MIB contain 394 references to objects in MPLS-LSR-STD-MIB. 396 - MPLS-LDP-GENERIC-STD-MIB, MPLS-LDP-ATM-STD-MIB and MPLS-LDP- 397 FRAME-RELAY-STD-MIB contain references to objects in MPLS- 398 LDP-STD-MIB. 400 - MPLS-FTN-STD-MIB contains references to objects in MPLS-TE- 401 STD-MIB. 403 Note that there is a textual convention (MplsIndexType) defined 404 in MPLS-LSR-STD-MIB that is imported by MPLS-LDP-STD-MIB. 406 4.12. Dependencies on External MIB Modules 408 With the exception of MPLS-TC-STD-MIB, all the MPLS MIB modules 409 have dependencies on the Interfaces MIB [RFC2863]. MPLS-FTN-STD-MIB 410 references IP-capable interfaces on which received traffic is to 411 be classified using indexes in the Interface Table (ifTable) of 412 IF-MIB [RFC2863]. The other MPLS MIB modules reference MPLS- 413 capable interfaces in ifTable. 415 The Interfaces Group of IF-MIB [RFC2863] defines generic managed 416 objects for managing interfaces. The MPLS MIB modules contain media- 417 specific extensions to the Interfaces Group for managing MPLS 418 interfaces. 420 The MPLS MIB modules assume the interpretation of the Interfaces 421 Group to be in accordance with [RFC2863] which states that ifTable 422 contains information on the managed resource's interfaces and that 423 each sub-layer below the internetwork layer of a network interface is 424 considered an interface. Thus, the MPLS interface is represented as 425 an entry in ifTable. 427 The inter-relation of entries in ifTable is defined by the Interfaces 428 Stack Group defined in [RFC2863]. 430 Additionally, MPLS-LDP-ATM-STD-MIB imports the textual convention 431 AtmVpIdentifier from ATM-TC-MIB to represent an ATM virtual path 432 identifier, while MPLS-LDP-FRAME-RELAY-STD-MIB imports the textual 433 convention DLCI from FRAME-RELAY-DTE-MIB to represent a Data Link 434 Channel identifier. 436 MPLS-LDP-STD-MIB imports the textual conventions IndexInteger and 437 IndexIntegerNextFree from [RFC3289], and MPLS-TE-STD-MIB imports 438 IndexIntegerNextFree. IndexInteger provides a standard arbitrary 439 index while IndexIntegerNextFree is used by a management agent 440 that needs to select an appropriate value for an arbitrary index. 442 Finally, all of the MIB modules import standard textual conventions 443 such as integers, strings, timestamps etc. from the MIB modules in 444 which they are defined. This is business as usual for a MIB module 445 and is not discussed further in this document. 447 5. Tables, Scalars and Notifications in MPLS-LSR-STD-MIB 449 5.1. Tables 451 MPLS-LSR-STD-MIB contains the following tables. 453 - The interface configuration table (mplsInterfaceTable) 454 is used for enabling MPLS on MPLS-capable interfaces. 456 - The in-segment (mplsInSegmentTable) and out-segment 457 (mplsOutSegmentTable) tables are used to configure and monitor LSP 458 segments carrying data into and out of the LSR, respectively. 460 - The in-segment mapping table (mplsInSegmentMapTable) provides a 461 look-up table that enables the discovery of an in-segment in 462 mplsInSegmentTable from the known incoming interface and incoming 463 label. 465 - The cross-connect table (mplsXCTable) is used to 466 associate in and out segments in order to form a cross- 467 connect (i.e. to represent an LSP transiting the LSR). 469 - The label stack table (mplsLabelStackTable) allows the 470 specification of multi-label stacks to be imposed on a 471 given LSP at this LSR 473 - The MPLS in-segment (mplsInSegmentPerfTable) and out- 474 segment (mplsOutSegmentPerfTable) performance tables 475 contain objects to measure the performance of LSPs. 477 - The MPLS interface performance table (mplsInterfacePerfTable) 478 has objects to measure MPLS performance on a per-interface basis. 480 5.2. Scalars 482 Where tables in the MIB module have arbitrary indexes, scalars are 483 provided to supply the next available index. This applies to 484 mplsInSegmentTable, mplsOutSegmentTable, mplsXCTable and 485 mplsLabelStackTable, but see the section on indexing, below. 487 mplsMaxLabelStackDepth defines the maximum size of a imposed label 488 stack supported at this LSR (and not, as the description in 489 MPLS-LSR-STD-MIB states, the maximum label stack depth supported by 490 the LSR). 492 mplsXCNotificationsEnable is used to enable and disable notifications 493 from MPLS-LSR-STD-MIB. 495 5.3. Indexing 497 Note that the indexing used by the tables in MPLS-LSR-STD-MIB is 498 unusual. A specific textual convention, MplsIndexType, is defined 499 in the MIB module and is used as the type for indexes to 500 mplsInSegmentTable, mplsOutSegmentTable, mplsXCTable and 501 mplsLabelStackTable. The textual convention is defined as an 502 octet string of between one and twenty four octets inclusive. 504 While this convention can be used to map simple integers and so 505 preserve the normal indexing techniques, it may also be used to 506 encode more complex indexing rules that may be useful to 507 implementations that subdivide their label spaces according to 508 physical or implementation constraints (such as placing the 509 responsibility for a subset of labels with a line card). 511 Note that it would be unusual, but not impossible, to make 512 sophisticated use of these indexes in a write-access MIB since 513 it would be hard to determine the 'next' index value. Thus, 514 non-simple values are likely only to be used in read-only MIBs 515 where the indexes are generated as a result of signaling protocol 516 implementations or other configuration means. The formatting and 517 interpretation of non-simple indexes is out of the scope of the 518 MIB module definition and is expected to be part of the 519 manageability statement for a particular device. When the 520 formatting is not known by an agent, it should treat the index as 521 a plain octet string containing an integer of between one and twenty 522 four octets. 524 As described in the previous section, scalars are provided to 525 allow agents to discover a suitable value to use as an index when 526 creating a new row in one of these tables. These scalars all use 527 a second textual convention, MplsIndexNextType, also defined within 528 MPLS-LSR-STD-MIB. This textual convention allows the 'null string', 529 that is a string of length one octet with value 0x00. The null string 530 is used to indicate that either write access is not supported or no 531 more indexes are currently available. 533 Note that the usage of the nextIndex scalars is such that at any time 534 a scalar supplies a value that is currently unused as an index to the 535 specific table. In order to avoid lacunae in the indexing of a table 536 under normal usage, implementations are recommended to only change 537 the value in an nextIndex scalar when the index is used (that is, 538 when a row is created) and not when the nextIndex scalar is read. In 539 a 'busy' table this may result in row creation attempts failing and 540 agents having to re-read the scalar before making a second row 541 creation attempt. The desire to avoid this issue is in opposition to 542 the desire to avoid lacunae. 544 5.4. Notifications 546 MPLS-LSR-STD-MIB can issue two notifications (if notifications 547 are enabled). 549 - mplsXCUp reports when a cross-connect becomes active. 551 - mplsXCDown reports when a cross-connect becomes 552 inactive. 554 5.5. Dependencies Between MIB Module Tables 556 The tables in MPLS-LSR-STD-MIB are related as shown on the 557 diagram below. The arrows indicate a reference from one 558 table to another. 560 Note that the various MIB tables contain two instances of pointers 561 to external tables that are not currently defined. Entries in an 562 external Traffic Parameters Table (external_Traffic_Table) are 563 pointed to using RowPointers from the mplsInSegmentTable 564 (mplsInSegmentTrafficParamPtr) and from the mplsOutSegmentTable 565 (mplsOutSegmentTrafficParamPtr) to allow representation of the 566 traffic parameters for the MPLS segment - alternatively, the 567 pointers may indicate an entry in the Tunnel Resource Table 568 (mplsTunnelResourceTable) in MPLS-TE-STD-MIB. Similarly, an 569 external label table may be used to store label values if, for 570 some reason they are not stored in place within the LSR MIB tables. 571 This might occur if extra per label space information needs to be 572 stored, and paves the way for GMPLS where labels cannot always be 573 stored in a 32 bit value. RowPointers are used from the 574 mplsInSegmentTable (mplsInSegmentLabelPtr), the mplsOutSegmentTable 575 (mplsOutSegmentTopLabelPtr), and from the mplsLabelStackTable 576 (mplsLabelStackLabelPtr). 578 mplsInterfacePerfTable 579 ^ 580 | 581 V 582 mplsInterfaceTable 583 ^ ^ 584 mplsInSegmentMapTable | | mplsLabelStackTable 585 | | | ^ | 586 | +----+ +----+ | | 587 | | | | | 588 | | external_Traffic_Table | | | 589 | | ^ ^ | | | 590 V | | | | | | 591 mplsInSegmentTable mplsOutSegmentTable | 592 | ^ ^ ^ ^ | | 593 | | | | | | V 594 +------+ | +----> mplsXCTable <----+ | +--+ 595 | V V | 596 | mplsInSegmentPerfTable mplsOutSegmentPerfTable | 597 | | 598 +--------------> external_Label_Table <-------------+ 600 6. Tables, Scalars and Notifications in the LDP MIB 602 6.1. MIB Modules 604 The MIB document for LDP contains four MIB modules. This 605 structure makes it easier for an implementation to select 606 only those modules that are relevant to it. The MIB Modules 607 are MPLS-LDP-STD-MIB, MPLS-LDP-GENERIC-STD-MIB, MPLS-LDP- 608 ATM-STD-MIB and MPLS-LDP-FRAME-RELAY-STD-MIB. 610 MPLS-LDP-STD-MIB defines objects which are specific to LDP 611 without any Layer 2 objects. MPLS-LDP-GENERIC-STD-MIB 612 defines Layer 2 Per Platform Label Space objects for use 613 with MPLS-LDP-STD-MIB and for use on Ethernet. MPLS-LDP-ATM- 614 STD-MIB defines Layer 2 Asynchronous Transfer Mode (ATM) 615 objects for use with MPLS-LDP-STD-MIB. MPLS-LDP-FRAME-RELAY- 616 STD-MIB defines Layer 2 FRAME-RELAY objects for use with 617 MPLS-LDP-STD-MIB. 619 The MPLS-LDP-STD-MIB module provides the core support and is 620 typically supported along with at least one of the Layer 2 621 MIB modules. 623 6.2. Tables 625 The tables in the LDP MIB for configuring the LDP behavior 626 of an LSR are as follows. 628 - The LDP Entity Table (mplsLdpEntityTable) provides a way to 629 configure the LSR for using LDP. There must be at least one LDP 630 Entity for the LSR to support LDP. Each entry/row in this table 631 represents a single LDP Entity. 633 - Several tables exist to help configure LDP's use of labels. These 634 are spread through the MIB modules described in the previous 635 section. They are: mplsLdpEntityGenLRTable, 636 mplsLdpEntityAtmParmsTable and mplsLdpEntityAtmLRTable, 637 mplsLdpEntityFrameRelayParmsTable and mplsLdpEntityFrLRTable. 638 They are used to configure generic, ATM and Frame Relay labels as 639 their names suggest. 641 - The LDP Peer Table (mplsLdpPeerTable) is a read-only table, that 642 contains information about LDP Peers known to LDP Entities. 644 - The LDP Hello Adjacencies Table (mplsLdpHelloAdjacencyTable) is a 645 table of all adjacencies between all LDP Entities and all LDP 646 Peers. 648 - Several tables exist to monitor and control LDP sessions. The LDP 649 Session Table (mplsLdpSessionTable) represents sessions between an 650 LDP Entity and a Peer. mplsLdpAtmSesTable and 651 mplsLdpFrameRelaySesTable contain session information specific to 652 ATM. 654 - The MPLS LDP Session Peer Address Table (mplsLdpSesPeerAddrTable) 655 stores addresses learned after session initialization via Address 656 Message advertisement. 658 - The LDP FEC Table (mplsFecTable) represents FEC (Forwarding 659 Equivalence Class) information that may be in use on one or more 660 LSPs. The LDP LSP FEC Table (mplsLdpLspFecTable) shows the FECs 661 associated with each LSP. 663 - MPLS-LDP-STD-MIB has a mapping table (mplsLdpLspTable) which maps 664 the LDP MIB's representation of LDP sessions to the underlying LSR 665 MIB's representation of the LSPs created by these sessions by 666 pointing to mplsInSegmentTable, mplsOutSegmentTable and 667 mplsXCTable, respectively. 669 - Statistics may be gathered through the LDP Entity Statistics Table 670 (mplsLdpEntityStatsTable) and the LDP Session Statistics Table 671 (mplsLdpSesStatsTable) 673 6.3. Scalars 675 Where tables in the MIB modules have arbitrary indexes, 676 scalars are provided to supply the next available index. 677 This applies to mplsLdpEntityTable and mplsFecTable. 679 Two scalars exist to configure the LSR. The LSR ID is set in 680 mplsLdpLsrId, and the loop detection capabilities are reported 681 in mplsLdpLsrLoopDetectionCapable 683 6.4. Notifications 685 MPLS-LDP-STD-MIB defines four notifications that a device can 686 issue. 688 - mplsLdpInitSesThresholdExceeded is reported when the 689 number of Session Initialization messages exceeds a 690 configured threshold. 692 - mplsLdpPVLMismatch is issued if the Path Vector Limit 693 for a configured Entity and Peer do not match. 695 - mplsLdpSessionUp and mplsLdpSessionDown report the 696 transition of Session state. 698 No scalar object is provided to enable and disable 699 notifications from MPLS-LDP-STD-MIB. Instead, the implementer 700 is referred to [RFC3413]. 702 6.5. Dependencies Between MIB Module Tables 704 The many tables in the four LDP MIB modules are related as 705 shown on the diagram below. The arrows indicate a 706 reference from one table to another. Note that in many 707 cases the reference is through an augmentation of the 708 referenced table. 710 mplsLdpEntityGenLRTable ------------->+ 711 mplsLdpEntityAtmParmsTable ---------->+ 712 mplsLdpEntityAtmLRTable ------------->+ 713 mplsLdpEntityFrameRelayParmsTable --->+ 714 mplsLdpEntityFrLRTable -------------->+ 715 mplsLdpEntityStatsTable ------------->+ 716 | 717 mplsLdpHelloAdjacencyTable | 718 | | 719 | mplsLdpEntityTable <--+ 720 | ^ ^ 721 V | | 722 mplsLdpPeerTable <-+- mplsLdpSesPeerAddrTable 723 ^ | 724 | V 725 mplsLdpSessionTable 726 ^ ^ 727 | | 728 mplsLdpSesStatsTable ------+ +-- mplsLdpLspFecTable 729 mplsLdpAtmSesTable --------+ | | | 730 mplsLdpFrameRelaySesTable--+ | | V 731 | | mplsFecTable 732 | V 733 +-- mplsLdpLspTable 735 7. Tables, Scalars and Notifications in MPLS-TE-STD-MIB 737 7.1. Tables 739 MPLS-TE-STD-MIB contains the following tables. 741 - The Tunnel Table (mplsTunnelTable) is used to configure 742 and report MPLS tunnels. Note that reporting of 743 tunnels in this table at transit LSRs is optional. 745 Entries in mplsTunnelTable are indexed by four 746 objects. The source and destination LSR IDs give 747 context to the entry, and an index (mplsTunnelIndex) 748 identifies the tunnel itself. However, the fourth index 749 (mplsTunnelInstance) may give rise to some confusion since 750 its usage is not clearly explained. 752 The description says: "Uniquely identifies an instance 753 of a tunnel. It is useful to identify multiple 754 instances of tunnels for the purposes of backup and 755 parallel tunnels." In the case of backup tunnels, 756 multiple instances of the same tunnel may be defined, 757 but only one is active at any time. Different instances 758 may have different properties (such as explicit 759 routes), and one instance may be set up to protect 760 against failure of another. Parallel tunnels may be 761 used to provide load sharing or protection. 763 The mplsTunnelInstancePriority object is used to 764 indicate the precedence of tunnels with the same LSR 765 Ids and mplsTunnelIndex value. The mplsTunnelPrimaryInstance 766 object gives a quick reference back to the preferred instance 767 of the tunnel. 769 The mplsTunnelIndex value is typically signaled as 770 the Tunnel ID, and the mplsTunnelInstance as the LSP Id 771 in protocols where both fields exist. In protocols 772 where there is only one identifying index (usually 773 known as the LSP Id), only the mplsTunnelIndex is 774 signaled. 776 - The Resource Table (mplsTunnelResourceTable) is used to 777 configure resources to be requested on this tunnel. 778 The CRLDP resource table (mplsTunnelCRLDPResTable) is 779 used to request additional resource details that are 780 specific to tunnels signaled using CR-LDP. 782 - The routes requested, computed and actually used for a 783 tunnel are found in the Tunnel Hop Table 784 (mplsTunnelHopTable) Tunnel Computed Hop Table 785 (mplsTunnelCHopTable) and Tunnel Actual Hop Table 786 (mplsTunnelARHopTable). 788 - Statistics about the performance of tunnels may be 789 gathered through the Tunnel Performance Table 790 (mplsTunnelPerfTable). 792 7.2. Scalars 794 Where tables in the MIB module have arbitrary indexes, scalars 795 are provided to supply the next available index. This applies 796 to mplsTunnelTable, mplsTunnelResourceTable and 797 mplsTunnelHopTable. 799 Two scalars exist to configure the support for MPLS tunnels 800 on the LSR. mplsTunnelTEDistProto lists the signaling 801 methods and protocols supported. mplsTunnelMaxHops defines 802 the size of route that may be configured on the LSR. 804 Two further scalars enhance the statistics on the LSR by 805 counting the number of configured (mplsTunnelConfigured) 806 and active (mplsTunnelActive) tunnels. 808 The scalar mplsTunnelNotificationMaxRate is used to control the rate 809 at which notifications are issued from MPLS-TE-STD-MIB. A rate of 810 zero means that notifications must not be issued. If notifications 811 would be generated faster than the configured rate an implementation 812 may choose to discard notifications or queue them for distribution 813 at a quieter time. 815 7.3. Notifications 817 MPLS-TE-STD-MIB defines four notifications that a device can 818 issue. The rate of dispatch of notifications is controlled as 819 described in the previous section. 821 - mplsTunnelUp and mplsTunnelDown report the transition 822 of Tunnel state. 824 - Rerouting and re-optimization of Tunnels paths are 825 reported by mplsTunnelRerouted and 826 mplsTunnelReoptimized. 828 7.4. Dependencies Between MIB Module Tables 830 The tables in MPLS-TE-STD-MIB are related as shown on the 831 diagram below. The arrows indicate a reference from one 832 table to another. 834 mplsTunnelPerfTable 835 ^ 836 | 837 V 838 mplsTunnelTable 839 | | 840 V | 841 mplsTunnelResourceTable +--> mplsTunnelHopTable 842 ^ | 843 | +--> mplsTunnelCHopTable 844 V | 845 mplsTunnelCRLDPResTable +--> mplsTunnelARHopTable 847 8. Tables, Scalars and Notifications in MPLS-FTN-STD-MIB 849 8.1. Tables 851 MPLS-FTN-STD-MIB contains the following tables. 853 - The FEC-to-NHLFE Table (mplsFTNTable) defines the FEC to NHLFE 854 rules to be applied to incoming packets, and the actions to be 855 taken on matching packets. 857 - The FEC-to-NHLFE Mapping Table (mplsFTNMapTable) provides 858 the capability to activate FTN rules defined in the 859 mplsFTNTable on specific interfaces in the system. 861 - Performance statistics for FTN rules are found in the 862 mplsFTNPerfTable. 864 8.2. Scalars 866 This MIB module contains the scalars mplsFTNTableLastChanged and 867 mplsFTNMapTableLastChanged to indicate the last time an object 868 changed in mplsFTNTable and mplsFTNMapTable respectively. Another 869 scalar, mplsFTNIndexNext, is used to supply the next valid index for 870 creating new conceptual rows in mplsFTNTable. 872 8.3. Notifications 874 There are no notifications in this MIB module. 876 8.4. Dependencies Between MIB Module Tables 878 The tables in MPLS-FTN-STD-MIB are related as shown on the diagram 879 below. The arrows indicate a reference from one table to another. 881 mplsFTNTable 882 ^ 883 | 884 mplsFTNMapTable 885 ^ 886 | 887 mplsFTNPerfTable 889 9. Tables and Objects in TE-LINK-STD-MIB 891 9.1. Tables 893 TE-LINK-STD-MIB contains the following tables. 895 - The TE link table (teLinkTable) is used to specify TE links, 896 including bundled links, and their generic traffic engineering 897 parameters. 899 - The TE link descriptor table (teLinkDescriptorTable) is used to 900 list the TE link descriptors. 902 - The shared risk link group (SRLG) table (teLinkSrlgTable) is used 903 to specify the SRLGs associated with TE links. 905 - The TE link bandwidth table (teLinkBandwidthTable) is used to 906 report priority-based bandwidth values associated with TE links. 908 - The component link table 909 (componentLinkTable) is used to identify the data- 910 bearing component links that are associated with the 911 TE links and specify the data-bearing link generic traffic 912 engineering parameters. 914 - The component link descriptor table 915 (componentLinkDescriptorTable) is used to list the 916 data-bearing component link descriptors. 918 - The component link bandwidth table 919 (componentLinkBandwidthTable) is used to report 920 priority-based bandwidth values associated with data- 921 bearing component links. 923 9.2. Scalars 925 There are no scalars in this MIB module. 927 9.3. Notifications 929 There are no notifications in this MIB module. 931 9.4. Dependencies Between MIB Module Tables 933 The tables in TE-LINK-STD-MIB are related as shown on the 934 diagram below. The arrows indicate a reference from one 935 table to another. 937 Note that many of the associations between tables are 938 through a common index that is the ifIndex of the related 939 interface. 941 teLinkTable 942 ^ 943 | 944 teLinkDescriptorTable ---+ 945 | 946 teLinkSrlgTable ---------+ 947 | 948 teLinkBandwidthTable ----+ 950 componentLinkTable 951 ^ 952 | 953 componentLinkDescriptorTable ---+ 954 | 955 componentLinkBandwidthTable ----+ 957 10. Table Dependencies Between MPLS MIB Modules 959 Section 4.11 gave an overview of how the MPLS MIB modules 960 are related. Now that the tables in the MIB modules have 961 been introduced, it is possible to give a more detailed 962 diagram of these relationships. 964 MPLS-TC-STD-MIB is left off the diagram since so many of the 965 MIB module tables use textual conventions from that MIB 966 module. 968 mplsLsrXCTable mplsLsrInSegmentTable 969 ^ ^ 970 | | 971 +---- mplsLdpLspTable 972 | | 973 mplsTunnelTable ------+ V 974 ^ | mplsLsrOutSegmentTable 975 | | 976 mplsFTNTable ---------+ 978 11. A Note on Interfaces 980 The Interfaces Group of IF-MIB [RFC2863] defines generic 981 managed objects for managing interfaces. The MPLS MIB modules 982 make references to interfaces in order that it can be clearly 983 determined where the procedures managed by the MIB modules 984 should be performed. Additionally, the MPLS MIB modules 985 (notably MPLS-TE-STD-MIB and TE-LINK-STD-MIB) utilize interface 986 stacking within the Interface Group. 988 11.1. MPLS Tunnels as Interfaces 990 MPLS-TE-STD-MIB builds on the concept of managing MPLS 991 Tunnels as logical interfaces. [RFC2863] states that the 992 interfaces table (ifTable) contains information on the 993 managed resource's interfaces, and that each sub-layer 994 below the internetwork layer of a network interface is 995 considered an interface. Thus, an MPLS Tunnel managed as 996 an interface is represented as an entry in the ifTable. 997 The interrelation of entries in the ifTable is defined by 998 the Interfaces Stack Group defined in [RFC2863]. 1000 When using MPLS Tunnels as interfaces, the interface stack 1001 table might appear as follows: 1003 +------------------------------------------------+ 1004 | MPLS tunnel interface ifType = mplsTunnel(150) | 1005 +------------------------------------------------+ 1006 | MPLS interface ifType = mpls(166) | 1007 +------------------------------------------------+ 1008 | Underlying layer | 1009 +------------------------------------------------+ 1010 In the diagram above, "Underlying layer" refers to the 1011 ifIndex of any interface type for which MPLS 1012 internetworking has been defined. Examples include ATM, 1013 Frame Relay, and Ethernet. 1015 A detailed listing of the mapping between ifTable objects 1016 and their use for MPLS Tunnels is given in [TEMIB]. A few 1017 key objects are listed here to provide an overview of the 1018 concepts. 1020 Each MPLS tunnel is represented by an entry in the ifTable. 1021 Each tunnel is therefore assigned a unique ifIndex. 1023 The type of an interface represented by an entry in the 1024 ifTable is indicated by the ifType object. The value that 1025 is allocated to identify an MPLS tunnel is 150. 1027 The ifOperStatus object reflects the actual operational 1028 status of MPLS tunnel and may be mapped from the 1029 mplsTunnelOperStatus object. 1031 It may be considered convenient and good management to set 1032 the ifName object to reflect the name of the MPLS tunnel as 1033 contained in the mplsTunnelName object. 1035 11.2. Application of the Interfaces Group to TE Links 1037 TE-LINK-STD-MIB also uses interface stacking to manage TE 1038 Link interfaces as logical interfaces. The TE Link interface 1039 is represented as an entry in the ifTable. The inter-relation 1040 of entries in the ifTable is defined by Interfaces Stack Group 1041 defined in [RFC2863]. When using TE Link interfaces, the 1042 interface stack table might appear as follows: 1044 +-------------------------------------------------------------------+ 1045 | MPLS interface ifType = mpls(166) | 1046 | ifIndex = 1 | 1047 +-------------------------------------------------------------------+ 1048 | TE link (bundled link) ifType = teLink(200) | 1049 | ifIndex = 2 | 1050 +--------------------------------+-+--------------------------------+ 1051 | TE link ifType = teLink(200) | | TE link ifType = teLink(200) | 1052 | ifIndex = 3 | | ifIndex = 4 | 1053 +--------------------------------+ +--------------------------------+ 1054 | Component link | | Component link | 1055 | ifType = opticalTransport(196) | | ifType = opticalTransport(196) | 1056 | ifIndex = 5 | | ifIndex = 6 | 1057 +--------------------------------+ +--------------------------------+ 1059 In the above diagram, "opticalTransport" is an example of an 1060 underlying physical interface: in this case an optical transport 1061 interface. TE link management and bundling can be seen in the levels 1062 of interface stacking. Two TE links are defined each managing an 1063 optical transport link. These two TE links are combined into a 1064 bundle which is managed as a single TE link interface. This TE Link 1065 interface supports MPLS and is presented as an MPLS interface. 1067 A detailed listing of the mapping between ifTable objects 1068 and their use for TE Links is given in [TELMIB]. A few key 1069 objects are listed here to provide an overview of the 1070 concepts. 1072 Each TE Link interface is represented by a separate entry 1073 in the ifTable with a unique ifIndex. 1075 The type of an interface represented by an entry in the 1076 ifTable is indicated by the ifType object. The value that 1077 is allocated to identify a TE Link 200. 1079 11.3. References to Interface MIB Objects from MPLS MIB Modules 1081 MPLS-TE-STD-MIB contains two objects that reference the 1082 management of an MPLS tunnel as an interface. 1083 mplsTunnelIsIf is a TruthValue that indicates whether the 1084 tunnel is present in the ifTable. If the tunnel is managed 1085 as an interface, the mplsTunnelIfIndex object contains the 1086 ifIndex that identifies the corresponding entry in the 1087 ifTable. 1089 MPLS-LSR-STD-MIB includes a table (mplsInterfaceTable) 1090 for configuring the support for MPLS on specific 1091 interfaces. A conceptual row in this table is created 1092 automatically by an LSR for every interface that is capable 1093 of and configured for support of MPLS. A conceptual row in 1094 this table will exist if and only if a corresponding entry 1095 in ifTable exists with ifType = mpls(166). The fate of the 1096 entries in the two tables are closely linked so that if the 1097 entry in the ifTable is operationally disabled, the entry 1098 in mplsInterfaceTable is deleted. During the life 1099 of an entry in mplsInterfaceTable a corresponding 1100 entry is managed in mplsInterfacePerfTable to show 1101 performance counters for the MPLS-capable interface. 1103 The ifIndex that identifies MPLS-capable interfaces also 1104 plays an important indexing role in MPLS-LSR-STD-MIB. In- 1105 segments (that is incoming LSP labels) are represented in 1106 mplsInSegmentTable which is indexed by the 1107 mplsInSegmentIfIndex and mplsInSegmentLabel objects. 1108 mplsInSegmentIfIndex is set to the ifIndex of the incoming 1109 MPLS-capable interface. mplsInSegmentLabel identifies the 1110 incoming MPLS label. Note that the corresponding 1111 mplsOutSegmentTable contains an mplsOutSegmentIfIndex 1112 object to identify the outgoing MPLS-capable interface, but 1113 that this does not form part of the index of the table. 1115 MPLS-LDP-STD-MIB use ifIndex extensively to identify the 1116 interface over which MPLS is active. 1118 Within MPLS-FTN-STD-MIB, mplsFTNMapTable maps entries 1119 in mplsFTNTable to interfaces on which mplsFTNTable 1120 entries should be activated. Interfaces are identified using 1121 their ifIndex values. 1123 12. Management Options 1125 It is not the intention of this document to provide 1126 instructions or advice to implementers of Management 1127 Stations, Management Agents or managed entities. It is, 1128 however, useful to make some observations about how the MIB 1129 modules described above might be used to manage MPLS 1130 systems. 1132 All MPLS LSPs may appear in MPLS-LSR-STD-MIB. At transit 1133 nodes they are seen as full cross-connects between incoming 1134 labels on incoming interfaces and outgoing labels on 1135 outgoing interfaces. At ingress or egress points the cross- 1136 connections are unbalanced having spoof upstream or 1137 downstream legs respectively. 1139 Split and merge points of LSPs may be represented as more 1140 complex cross-connects in MPLS-LSR-STD-MIB. Similarly, 1141 bidirectional LSPs can be represented by using the same 1142 cross-connect index for each of the forward and reverse 1143 cross-connections. 1145 The modules in the LDP MIB are intended solely for use with 1146 LDP and CR-LDP. LSPs that are signaled through other means 1147 may conveniently be stored in mplsLdpLspTable for 1148 consistency with LSPs set up using LDP, but there is little 1149 further value to this since the table gives only pointers 1150 into MPLS-LSR-STD-MIB. If, however, the LSPs are 1151 established with associated FECs using some signaling 1152 method other than LDP (for example, BGP) it may be 1153 advantageous to use mplsLdpLspTable, mplsFecTable and 1154 mplsLdpLspFecTable to correlate the LSPs. 1156 Note that if CR-LDP is the signaling protocol there is no 1157 requirement to use the LSP-related tables in the LDP MIB 1158 since the LSP will be adequately represented in MPLS-TE- 1159 MIB and MPLS-LSR-STD-MIB. 1161 MPLS tunnels may be represented in MPLS-TE-STD-MIB with 1162 their cross-connects indicated in MPLS-LSR-STD-MIB. 1163 Tunnels are often (although not always) set up with a 1164 series of constraints that may be represented in MPLS- 1165 TE-STD-MIB. Note that a distinguishing feature of a tunnel is 1166 that it has an ingress and an egress, where LSPs 1167 established through LDP may be end-to-end or may be hop-by- 1168 hop. 1170 All LSPs (tunnels and non-tunnels) may be established as a 1171 result of signaling protocols already defined or for future 1172 study. In addition, LSPs may be manually set up by issuing 1173 configuration commands to each of the LSRs on the LSP. 1174 These commands may utilize SNMP by performing SET 1175 operations to the MIB module tables and objects described 1176 here. Alternatively, configuration may be through some non- 1177 standard interface such as a Command Line or a Graphical 1178 User Interface. Such configured LSPs may also be 1179 represented in the MIB module tables. 1181 Do not be mislead by considerations of the "permanence" of 1182 LSPs when deciding which tables of which MIB modules to 1183 use. An MPLS tunnel may have a very long life expectancy 1184 if set up by an amnesiac user, or a very short lifetime is 1185 automatically provisioned to satisfy on-demand traffic 1186 requirements. Similarly, an LSP established in response to 1187 a routing protocol (sometimes known as a hop-by-hop LSP) 1188 may be equally stable or unstable. 1190 13. Related IETF MIB Modules 1192 This section describes the broad interactions between MIB 1193 modules produced by the PWE3, PPVPN, and CCAMP working 1194 groups and the MPLS MIB modules. This information is provided 1195 as background information and is not central to this document. 1197 13.1. PWE3 Working Group MIB Modules 1199 The PWE3 working group has produced a document [PWE3FW] 1200 that includes a description of the framework for MIB modules 1201 within PWE3 operation. Since the PWE3 architecture includes 1202 the use of MPLS as an emulated service and as a PSN service, 1203 the MPLS MIB modules described above may be leveraged. The 1204 PWE3 framework document describes the interactions between 1205 the MPLS MIB modules and the PWE3 MIB modules. 1207 13.2. PPVPN Working Group MIB Modules 1209 At present, the PPVPN working group has not included a 1210 discussion of how the MPLS MIB modules interact with the MIB 1211 modules being produced by that working group. The authors of 1212 this document hope to make a forthcoming addition to the PPVPN 1213 framework document [PPVPNFW] detailing these interactions. 1214 At the moment, there are two MIB modules [VPNMIB] and [VPNTCMIB] 1215 which are discussed next. 1217 13.2.1. PPVPN-MPLS-VPN-STD-MIB 1219 PPVPN-MPLS-VPN-STD-MIB describes managed objects that are used 1220 to model and manage RFC2547bis MPLS VPNs [RFC2547Bis]. 1221 This MIB module contains tables which model virtual routing 1222 forwarding entries (VRFs), as well as the interfaces 1223 associated with those VRFs. 1225 13.2.1.1. Position in the OID Tree 1227 transmission -- RFC 2578 [RFC2578] 1228 | 1229 +- vpnMIB -- PPVPN-MPLS-VPN-STD-MIB 1231 13.2.1.2. Dependencies 1233 This MIB module currently has no direct dependencies to any 1234 of the MPLS MIB modules. This MIB module models MPLS VPN 1235 interfaces as entries in the Interfaces MIB's Interfaces 1236 Table (ifTable). This MIB module may be modified in the 1237 future to import textual conventions from MPLS-TC-STD-MIB. 1239 A specific textual conventions MIB module [VPNTCMIB] defines 1240 textual conventions that are imported into PPVPN-MPLS-VPN-STD-MIB. 1242 13.3. CCAMP Working Group MIB Modules 1244 The CCAMP working group is developing MIB modules in support of 1245 GMPLS that interact directly with the MPLS MIB modules. Along 1246 with any MIB modules produced by the CCAMP working group, a 1247 separate CCAMP-specific Management Framework document is expected 1248 to be issued describing the relationship between these MIB 1249 modules and the existing MPLS (and other) MIB modules. 1251 14. Traffic Engineering Working Group TE MIB 1253 The TEWG has produced a traffic engineering MIB (TE-MIB) 1254 [TEWGMIB] containing objects for monitoring traffic engineered 1255 tunnels at their ingress points. 1257 In many senses TE-MIB contains the same information as 1258 MPLS-TE-STD-MIB. Both MIB modules can be used to monitor MPLS 1259 tunnels; however, TE-MIB is minimalistic and caters best to 1260 TE tunnels as tunnels, at the expense of not having many advanced 1261 features of MPLS-TE-STD-MIB, whereas MPLS-TE-STD-MIB can 1262 deconstruct tunnels into hop-by-hop cross-connects, at the 1263 expense of more complexity. 1265 The TE-MIB module imports textual conventions from the MPLS-TC- 1266 STD-MIB module and so is dependent on that document. 1268 14.1. Choosing Between TE MIB Modules 1270 TE-MIB is a flexible MIB module designed to manage traffic 1271 engineering tunnels regardless of the implementation 1272 technology. This flexibility and a focus on simplicity leads 1273 to some compromises. 1275 - Some MPLS configuration parameters are left out. For example, 1276 the resource management in TE-MIB is confined to bandwidth, so 1277 missing the full IntServ control. 1279 - Other TE-MIB parameters are present but with only limited 1280 options. For example, the ability to configure different label 1281 distribution methods per LSP. 1283 Extensibility of TE-MIB to related concepts such as 1284 DiffServ and Fast Reroute, and integrations with other MIB 1285 modules such as that in MPLS-LSR-STD-MIB is not a work item 1286 at the time of writing. The MPLS MIB modules are more closely 1287 integrated as described in this document. 1289 Write/create access to TE-MIB is only available at the ingress, 1290 where it can be used to configure an ingress to signal a tunnel 1291 with constraints. It cannot be used to configure hop-by-hop 1292 cross-connects to build a tunnel. 1294 The purpose of TE-MIB module is to allow a Management Agent to 1295 configure tunnels, and to inspect and monitor all tunnels (however 1296 created) at their ingress points. It does not provide information 1297 about tunnels at any other point in the network (that is, at transit 1298 or egress nodes). This module can be used, for example, to configure 1299 the constraints of a tunnel, whereupon the ingress would compute the 1300 tunnel path and signal it. The MIB module can then be used at the 1301 ingress to monitor the tunnel's path(s), their status and the 1302 tunnel's uptime and counters. This MIB module is not designed to 1303 configure hop-by-hop cross-connects to build a tunnel. 1305 15. Security Considerations 1307 This document describes the inter-relationships amongst the 1308 different MIB modules relevant to MPLS management and as such does 1309 not have any security implications in and of itself. 1311 Each specific MIB document specifies specific MIB objects and such 1312 a document must provide a proper security considerations section that 1313 explains the security aspects of those objects. 1315 The attention of readers is particularly drawn to the security 1316 implications of making MIB objects available for create or write 1317 access through an access protocol such as SNMP. SNMPv1 by itself 1318 is such an insecure environment. Even if the network itself is 1319 secure (for example by using IPSec), there is no control over who 1320 on the secure network is allowed to access and GET (read) the 1321 objects in this MIB. It is recommended that the implementers 1322 consider the security features as provided by the SNMPv3 framework. 1323 Specifically, the use of the User-based Security Model STD 62, 1324 RFC 3414 [RFC3414] and the View-based Access Control Model STD 62, 1325 RFC 3415 [RFC3415] is recommended. 1327 It is then a customer/user responsibility to ensure that the SNMP 1328 entity giving access to an instance of this MIB, is properly 1329 configured to give access to only those objects, and to those 1330 principals (users) that have legitimate rights to access them 1332 16. Acknowledgements 1334 Many small pieces of text in this document have been borrowed 1335 from the documents that define the MIB modules described here. 1336 The authors would like to express appreciation to all who 1337 worked on those MIB documents. 1339 Thanks also to all those who attended the November 2002 1340 MPLS MIB open meeting and gave constructive feedback, and 1341 in particular to Sharon Chisholm for her thoughts on 1342 Management Options. 1344 Thanks to Kireeti Kompella for revising the text on TE-MIB. 1346 Without the consistent pressure and encouragement from 1347 Bert Wijnen, this document would not have been written. 1349 17. Intellectual Property Consideration 1351 The IETF takes no position regarding the validity or scope 1352 of any intellectual property or other rights that might be 1353 claimed to pertain to the implementation or use of the 1354 technology described in this document or the extent to 1355 which any license under such rights might or might not be 1356 available; neither does it represent that it has made any 1357 effort to identify any such rights. Information on the 1358 IETF's procedures with respect to rights in standards-track 1359 and standards-related documentation can be found in BCP-11. 1360 Copies of claims of rights made available for publication 1361 and any assurances of licenses to be made available, or the 1362 result of an attempt made to obtain a general license or 1363 permission for the use of such proprietary rights by 1364 implementers or users of this specification can be obtained 1365 from the IETF Secretariat. 1367 The IETF invites any interested party to bring to its 1368 attention any copyrights, patents or patent applications, or 1369 other proprietary rights which may cover technology that may 1370 be required to practice this standard. Please address the 1371 information to the IETF Executive Director. 1373 18. Normative References 1375 [FTNMIB] Nadeau, T., Srinivasan, C., and A. Viswanathan, 1376 "Multiprotocol Label Switching (MPLS) Forwarding 1377 Equivalence Class To Next Hop Label Forwarding 1378 Entry (FEC-To-NHLFE) Management Information Base", 1379 Internet Draft , 1380 August 2003 (work in progress). 1382 [LDPMIB] J. Cucchiara, et al., "Definitions of 1383 Managed Objects for the Multiprotocol Label 1384 Switching, Label Distribution Protocol 1385 (LDP)", , 1386 August 2003 (work in progress). 1388 [LSRMIB] Srinivasan, C., Viswanathan, A. and T. Nadeau, 1389 "MPLS Label Switching Router Management Information 1390 Base", Internet Draft , 1391 August 2003 (work in progress). 1393 [RFC2863] McCloghrie, K. and F. Kastenholtz, "The 1394 Interfaces Group MIB ", RFC 2863, June 2000. 1396 [RFC3289] Baker, F., Chan, K. and A. Smith, "Management 1397 Information Base for the Differentiated Services 1398 Architecture", RFC 3289, May 2002. 1400 [TCMIB] Nadeau, T., Cucchiara, J., (Editors) "Definitions of 1401 Textual Conventions for Multiprotocol Label Switching 1402 (MPLS) Management", Internet Draft , August 2003 (work in progress). 1405 [TELMIB] Dubuc, M., Dharanikota, S., Nadeau, T., J. Lang, 1406 "Traffic Engineering Management Information Base", 1407 Internet Draft , 1408 August 2003 (work in progress). 1410 [TEMIB] Srinivasan, C., Viswanathan, A. and T. 1411 Nadeau, "MPLS Traffic Engineering Management 1412 Information Base Using SMIv2", Internet 1413 Draft , 1414 August 2003 (work in progress). 1416 19. Informative References 1418 [PPVPNFW] Callon, R., Suzuki, M., (Editors) "A Framework 1419 for Layer 3 Provider Provisioned Virtual Private 1420 Networks", Internet Draft , March 2003 (work in progress). 1423 [PWE3FW] Pate, P., (Editor), "Framework for Pseudo Wire 1424 Emulation Edge-to-Edge (PWE3)", Internet Draft 1425 , June, 2002 1426 (work in progress). 1428 [RFC2026] S. Bradner, "The Internet Standards Process 1429 -- Revision 3", RFC 2026, October 1996. 1431 [RFC2401] Kent, S., and Atkinson, R., "Security 1432 Architecture for the Internet Protocol", RFC 1433 2401, November 1998. 1435 [RFC2547Bis] Rosen, E. et al, "MPLS/BGP VPNs", Internet 1436 Draft , 1437 October 2002. 1439 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., 1440 Case, J., Rose, M. and S. Waldbusser, "Structure 1441 of Management Information Version 2 (SMIv2)", 1442 STD 58, RFC 2578, April 1999. 1444 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., 1445 Case, J., Rose, M. and S. Waldbusser, "Textual 1446 Conventions for SMIv2", STD 58, RFC 2579, April 1447 1999. 1449 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., 1450 Case, J., Rose, M. and S. Waldbusser, "Conformance 1451 Statements for SMIv2", STD 58, RFC 2580, April 1999. 1453 [RFC2863] McCloghrie, K. and F. Kastenholtz, "The 1454 Interfaces Group MIB ", RFC 2863, June 2000. 1456 [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., 1457 "Multiprotocol Label Switching 1458 Architecture", RFC 3031, January 2001. 1460 [RFC3036] Andersson, L., Doolan, P., Feldman, N., 1461 Fredette, A., and B. Thomas, "LDP 1462 Specification", RFC 3036, January 2001. 1464 [RFC3410] Case, J., Mundy, R., Partain, D. and Stewart, B., 1465 "Introduction and Applicability Statements for 1466 Internet-Standard Management Framework", RFC 3410, 1467 December 2002. 1469 [RFC3413] Levi, D., Meyer, P., Stewart, B., "Simple Network 1470 Management Protocol (SNMP) Applications", RFC 3413 1471 December 2002. 1473 [RFC3414] Blumenthal, U., Wijnen, B., "User-based Security 1474 Model (USM) for version 3 of the Simple Network 1475 Management Protocol (SNMPv3)", RFC 3414, December 1476 2002. 1478 [RFC3415] Wijnen, B., Presuhn, R., McCloghrie, K., "View- 1479 based Access Control Model (VACM) for the Simple 1480 Network Management Protocol (SNMP)", RFC 3415, 1481 December 2002. 1483 [TEWGMIB] Kompella, K., "A Traffic Engineering MIB", 1484 Internet Draft , 1485 September 2002 (work in progress). 1487 [VPNMIB] Nadeau, T., et al., "MPLS/BGP Virtual Private 1488 Network Management Information Base Using SMIv2", 1489 Internet Draft, , November 2002 (work in progress). 1492 [VPNTCMIB] Schliesser, B., Nadeau, T., "Definition of 1493 Textual Conventions for Provider Provisioned 1494 Virtual Private Network (PPVPN) Management", 1495 Internet Draft, , November 2002 (work in progress). 1498 20. Authors' Addresses 1500 Thomas D. Nadeau 1501 Cisco Systems, Inc. 1502 300 Apollo Drive 1503 Chelmsford, MA 01824 1504 Phone: +1-978-244-3051 1505 Email: tnadeau@cisco.com 1507 Cheenu Srinivasan 1508 Bloomberg L.P., 1509 499 Park Avenue, 1510 New York, NY 10022 1511 Tel: (212) 893-3682 1512 Email: cheenu@bloomberg.net 1514 Adrian Farrel 1515 Old Dog Consulting 1516 Tel: +44 (0) 1978 860944 1517 Email: adrian@olddog.co.uk 1519 21. Full Copyright Statement 1521 Copyright (C) The Internet Society (2003). All Rights 1522 Reserved. 1524 This document and translations of it may be copied and 1525 furnished to others, and derivative works that comment on 1526 or otherwise explain it or assist in its implementation may 1527 be prepared, copied, published and distributed, in whole or 1528 in part, without restriction of any kind, provided that the 1529 above copyright notice and this paragraph are included on 1530 all such copies and derivative works. However, this 1531 document itself may not be modified in any way, such as by 1532 removing the copyright notice or references to the Internet 1533 Society or other Internet organizations, except as needed 1534 for the purpose of developing Internet standards in which 1535 case the procedures for copyrights defined in the Internet 1536 Standards process must be followed, or as required to 1537 translate it into languages other than English. 1539 The limited permissions granted above are perpetual and 1540 will not be revoked by the Internet Society or its 1541 successors or assigns. This document and the information 1542 contained herein is provided on an "AS IS" basis and THE 1543 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 1544 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1545 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1546 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1547 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 1548 PURPOSE.