idnits 2.17.1 draft-ietf-mpls-ftn-mib-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1968 has weird spacing: '...andards rela...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (October 2003) is 7471 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3289' is defined on line 1836, but no explicit reference was found in the text == Unused Reference: 'RFC3291' is defined on line 1840, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 1880, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3291 (Obsoleted by RFC 4001) -- Possible downref: Non-RFC (?) normative reference: ref. 'LSRMIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'TEMIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'TCMIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLSMGMT' -- Obsolete informational reference (is this intentional?): RFC 1519 (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 11 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 Expires: March 2004 4 Cheenu Srinivasan 5 Bloomberg L.P. 7 Arun Viswanathan 8 Force10 Networks, Inc. 10 October 2003 12 Multiprotocol Label Switching (MPLS) Forwarding Equivalence 13 Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) 14 Management Information Base 16 draft-ietf-mpls-ftn-mib-09.txt 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC 2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other 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 accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This memo defines a portion of the Management Information Base (MIB) 42 for use with network management protocols in the Internet community. 43 In particular, it describes managed objects for defining, configuring 44 and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label 45 Forwarding Entry (NHLFE) mappings and corresponding actions for use 46 with Multiprotocol Label Switching (MPLS). 48 Table of Contents 50 1. Introduction .............................................. 2 51 2. Terminology ............................................... 3 52 3. Conventions Used In This Document ......................... 3 53 4. The Internet-Standard Management Framework ................ 3 54 5. Outline ................................................... 4 55 5.1. mplsFTNTable ........................................... 4 56 5.1.1.Advantages of Address Ranges Over CIDR Prefixes ........ 4 57 5.2. mplsFTNMapTable ........................................ 5 58 5.2.1.Indexing Requirements .................................. 5 59 5.2.2.How the Current Indexing Works ......................... 6 60 5.3. mplsFTNPerfTable ....................................... 7 61 6. Avoiding Retrieval-Modification Interactions .............. 7 62 7. Example Illustrating MIB Module Components ................ 8 63 7.1. Sample FTN Rules ....................................... 8 64 7.2. Creating FTN Entries and Applying them to Interfaces ... 9 65 7.3. Mapping an FTN Entry to Multiple Interfaces ........... 10 66 7.4. Inserting an Entry Into Existing List ................. 11 67 7.5. Pictorial Tabular Relationship ........................ 12 68 7.6. Deleting an Entry ..................................... 13 69 8. The Use of RowPointer .................................... 15 70 9. MPLS-FTN-STD-MIB Definitions ............................. 15 71 10. Security Considerations ............................... 36 72 11. IANA Considerations ................................... 37 73 11.1. IANA Considerations for MPLS-FTN-STD-MIB .............. 37 74 12. References ............................................ 37 75 12.1. Normative References .................................. 37 76 12.2. Informative References ................................ 38 77 13. Authors' Addresses .................................... 39 78 14. Acknowledgements ...................................... 40 79 15. Full Copyright Statement .............................. 40 80 16. Intellectual Property Considerations .................. 40 82 1. Introduction 84 This memo defines a portion of the Management Information Base (MIB) 85 for use with network management protocols in the Internet community. 86 In particular, it describes managed objects for specifying Forwarding 87 Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) 88 mappings and corresponding actions for Multiprotocol Label Switching 89 (MPLS). 91 At the ingress of an MPLS network, packets entering the MPLS domain 92 are assigned to a FEC. Those packets belonging to a FEC are 93 associated with a NHLFE (i.e. MPLS label) via the FEC-to-NHLFE (FTN) 94 mapping [RFC3031]. This relationship defines how ingress LSRs will 95 impose MPLS labels onto incoming packets. It also defines how egress 96 LSRs will decapsulate the MPLS shim header from MPLS packets. 98 Conceptually, some of the FTN table functionality could be 99 implemented using the Forwarding Information Base (FIB) to map all 100 packets destined for a prefix to an LSP. However, this mapping is 101 coarse in nature. 103 Similar functionality is already being used in other contexts such as 104 security filters, access filters, and for RSVP flow identification. 105 All of these require various combinations of matching based on IP 106 header and upper-layer header information to identify packets for a 107 particular treatment. When packets match a particular rule, a 108 corresponding action is executed on those packets. For example, two 109 popular actions to take when a successful match is identified are 110 allowing the packet to be forwarded or to discard it. However, other 111 actions are possible, such as modifying the TOS byte, or redirecting 112 a packet to a particular outgoing interface. In the context of MPLS, 113 the possible actions performed by an NHLFE are to redirect packets to 114 either an MPLS Label Switched Path (LSP) or an MPLS Traffic 115 Engineered (TE) Tunnel. 117 This document attempts to consolidate the various matching 118 requirements and associated action options needed for MPLS into a 119 single specification. 121 2. Terminology 123 Although all of the terminology used in this document is either 124 covered in the MPLS Architecture [RFC3031] or in the SNMP 125 Architecture [RFC3411], it is informational to define some 126 immediately pertinent acronyms/terminology here. 128 MPLS Multiprotocol Label Switching 129 FEC Forwarding Equivalence Class 130 NHLFE Next-Hop Label Forwarding Entry 131 FTN FEC-to-NHLFE 132 MIB Management Information Base 134 3. Conventions Used In This Document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 4. The Internet-Standard Management Framework 142 For a detailed overview of the documents that describe the current 143 Internet-Standard Management Framework, please refer to section 7 of 144 RFC 3410 [RFC3410]. 146 Managed objects are accessed via a virtual information store, termed 147 the Management Information Base or MIB. MIB objects are generally 148 accessed through the Simple Network Management Protocol (SNMP). 149 Objects in the MIB are defined using the mechanisms defined in the 150 Structure of Management Information (SMI). This memo specifies a MIB 151 module that is compliant to the SMIv2, which is described in STD 58, 152 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 153 [RFC2580]. 155 5. Outline 157 This MIB module resides on any LSR which does the FEC-to-NHLFE 158 mapping in order to map traffic into the MPLS domain. This MIB module 159 consists of three tables: 161 - mplsFTNTable defines the rule base against which incoming packets 162 are matched and actions taken on matching packets; 164 - mplsFTNMapTable defines the application of these rules to specific 165 interfaces; 167 - mplsFTNPerfTable provides performance counters for every entry in 168 mplsFTNTable that is active on one or more interfaces, on a per- 169 interface basis. 171 5.1. mplsFTNTable 173 This table allows FEC to NHLFE mappings to be specified. Each entry 174 in this table (also referred to as an "FTN entry" in this document) 175 defines a rule to be applied to incoming packets (on interfaces that 176 the entry is activated on using mplsFTNMapTable as explained in 177 Section 5.2) and an action to be taken on matching packets. 178 mplsFTNTable allows 6-tuple matching rules based on one or more of 179 source address range, destination address range, source port range, 180 destination port range, IPv4 Protocol field [RFC791] or IPv6 next- 181 header field [RFC2460] and the DiffServ Code Point (DSCP, [RFC2474]) 182 to be specified. Packet redirection is based on an action pointer 183 which points either at an mplsXCEntry in MPLS-LSR-STD-MIB [LSRMIB] 184 when the NHLFE is a non-TE LSP, or at an mplsTunnelEntry in MPLS-TE- 185 STD-MIB [TEMIB] when the NHLFE is the origin of a TE tunnel. 187 5.1.1.Advantages of Address Ranges Over CIDR Prefixes 189 One possible way to specify a set of addresses as part of an FTN rule 190 is to use CIDR prefixes [RFC1519]. We have instead chosen to allow 191 FTN rules to be expressed in terms of address ranges in mplsFTNTable 192 because they have the following advantages. 194 - The number of CIDR prefixes needed to represent some address 195 ranges is very large. For example, we need the following 6 CIDR 196 prefixes to represent the range of addresses [192.0.2.0- 197 192.0.2.62]: 192.0.2.0/27, 192.0.2.32/28, 192.0.2.48/29, 198 192.0.2.56/30, 192.0.2.60/31, and 192.0.2.62/32. A rule such as 199 "redirect all packets with a source address in the range 200 [192.0.2.0-192.0.2.62] and destination address in the range 201 [192.0.2.128-192.0.2.190] to tunnel #2" would require the 202 creation of 36 conceptual rows in mplsFTNTable if the rules were 203 expressed as CIDR prefixes but only a single conceptual row if we 204 used address ranges instead. 206 - Every CIDR prefix can be expressed as a single equivalent address 207 range. 209 - A particular implementation is free to translate the address 210 ranges specified in mplsFTNTable internally to equivalent CIDR 211 prefixes, if it so chooses. However, given that powerful range 212 matching algorithms are available, many implementations may 213 prefer to implement these directly. 215 5.2. mplsFTNMapTable 217 This table provides the capability to activate or map FTN entries 218 defined in mplsFTNTable to specific interfaces in the system. 219 Packets received on an interface are compared against FTN entries in 220 the order in which these entries are applied to the interface. 222 5.2.1.Indexing Requirements 224 The indexing structure of mplsFTNMapTable was designed to satisfy the 225 following requirements. 227 - We must be able to insert a new entry into an existing list of 228 entries on an interface with a single SET operation. Thus, we 229 must be able to support an insertion operation that does not 230 require manual reindexing of existing entries. 232 - A management application must be able to traverse entries that 233 have been applied to a particular interface in the order of 234 application. The number of (non-bulk) retrieval operations to 235 obtain this information as dictated by the particular indexing 236 scheme that we choose for mplsFTNMapTable must be no more than 237 that dictated by any other indexing scheme. For example, the 238 indexing scheme must not force the Network Management Application 239 to retrieve all the entries in the table and sift through them 240 offline to obtain this information. 242 5.2.2.How the Current Indexing Works 244 The natural data-structure for implementing constant time insertions 245 between two existing entries and for supporting in-order traversals 246 is a linked-list. 248 The chosen indexing structure of mplsFTNMapTable makes the entries in 249 the table behave like items in a linked-list. Each conceptual row 250 has an object, mplsFTNMapPrevIndex, which is a pointer to the 251 previous entry that is applied to a particular interface. This 252 object is self-adjusting, i.e. its value is automatically adjusted by 253 the agent, if necessary, after an insertion or deletion operation. 255 This indexing scheme provides a mechanism to 'insert' an FTN entry 256 between two existing entries already applied on an interface. This 257 is done by specifying the entry after which a new entry should be 258 inserted in mplsFTNMapPrevIndex. 260 Using this linked-list structure, one can retrieve FTN entries in the 261 order of application on a per-interface basis as follows: 263 - To determine the first FTN entry on an interface with index 264 ifIndex perform a GETNEXT retrieval operation on 265 mplsFTNMapRowStatus.ifIndex.0.0; the returned object, if one 266 exists, is (say) mplsFTNMapRowStatus.ifIndex.0.n 267 (mplsFTNMapRowStatus is the first accessible columnar object in 268 the conceptual row). Then the index of the first FTN entry 269 applied on this interface is n. 271 - To determine the FTN entry applied to an interface after the one 272 indexed by n perform a GETNEXT retrieval operation on 273 mplsFTNMapRowStatus.ifIndex.n.0. If such an entry exists the 274 returned object would be of the form 275 mplsFTNMapRowStatus.ifIndex.n.m. Then the index of the next FTN 276 entry applied on this interface is m. 278 - If the FTN entry indexed by n is the last entry applied to the 279 interface with index ifIndex then the object returned would 280 either be: 282 1.mplsFTNMapRowStatus.ifIndexNext.0.k, where ifIndexNext is the 283 index of the next interface in ifTable to which an FTN entry 284 has been applied, in which case k is the index of the first FTN 285 entry applied to the interface with index ifIndexNext; 287 or: 289 2.mplsFTNMapStorageType.firstIfIndex.0.p, if there are no more 290 entries in mplsFTNMapTable, where firstIfIndex is the first 291 entry in ifTable to which an FTN entry has been mapped. 293 The above steps can be used to retrieve all the applied entries on a 294 per-interface basis in application order. Note that the number of 295 retrieval operations is equal to the number of applied FTN entries 296 (i.e. the minimum number of GETNEXT operations needed using any 297 indexing scheme). 299 Also note that we could not have created this linked-list structure 300 using a 'next' pointer object instead of the 'previous' pointer 301 object that we chose because this would not allow us to determine the 302 first FTN entry that has been mapped to a specific interface using a 303 single SNMP (non-bulk) retrieval operation. 305 The use of this indexing structure is further illustrated using an 306 example in Section 7. 308 5.3. mplsFTNPerfTable 310 If an FTN entry has been applied to one or more interfaces, this 311 table provides high-capacity performance counters to monitor each 312 such FTN entry on a per-interface basis. 314 6. Avoiding Retrieval-Modification Interactions 316 The problem of an ongoing traversal or retrieval operation on an SNMP 317 table being affected by a concurrent modification operation on that 318 table is not unique to this MIB module. However, it is useful to 319 note that a cautious application can keep track of the state of the 320 the modifiable tables in this MIB module using the objects 321 mplsFTNTableLastChanged and mplsFTNMapTableLastChanged. 323 For instance, before performing a traversal of mplsFTNMapTable, the 324 application should retrieve the value of mplsFTNMapTableLastChanged. 325 Each subsequent GETNEXT operation on the table should include this 326 object as well. For example, GETNEXT(mplsFTNMapTableLastChanged.0, 327 mplsFTNMapRowStatus.ifIndex.n.0) can be used to: 329 - Determine the FTN entry after the one indexed by n (in linked-list 330 order) mapped to the interface with index ifIndex, as explained 331 in Section 5.2.2; 333 - Verify by comparing the value of mplsFTNMapTableLastChanged 334 retrieved by this operation with the value retrieved before the 335 traversal was begun that mplsFTNMapTable was not modified during 336 the retrieval process. 338 Using this technique an application can ensure the validity of the 339 retrieved information with minimal overhead. This is particularly 340 important while retrieving information from frequently modified 341 tables. 343 7. Example Illustrating MIB Module Components 345 In this section we use an example to illustrate how the objects 346 defined in MPLS-FTN-STD-MIB work together to perform FEC to NHLFE 347 mapping. 349 Note that for the various table entries involved in this example we 350 only show the objects that help illustrate each case. 352 7.1. Sample FTN Rules 354 Suppose that we wish to activate the following two FTN rules. 356 Rule #1: On interface ifIndex = 1 redirect packets with source IPv4 357 address matching 192.0.2.63 to an LSP with outgoing ifIndex = 50 358 and outgoing label = 150 360 where the specified LSP is represented by the following entries in 361 mplsXCTable and mplsOutSegmentTable. 363 In mplsXCTable: 364 { 365 mplsXCIndex = 0x02, 366 mplsXCInSegmentIndex = 0x00, 367 mplsXCOutSegmentIndex = 0x03, 368 mplsXCLabelStackIndex = 0 369 } 370 The value 0x00 for mplsXCInSegmentIndex represents an originating 371 LSP [LSRMIB]. 373 In mplsOutSegmentTable: 374 { 375 mplsOutSegmentIndex = 0x03, 376 mplsOutSegmentIfIndex = 50, 377 mplsOutSegmentPushTopLabel = true, 378 mplsOutSegmentTopLabel = 150 379 } 381 Rule #2: On interface ifIndex = 1 redirect packets with destination 382 IPv4 addresses in the range [192.0.2.32, 192.0.2.96] to tunnel #4 384 where the specified tunnel is represented by the following entry in 385 mplsTunnelTable: 386 { 387 mplsTunnelIndex = 4, 388 -- primary tunnel 389 mplsTunnelInstance = 0, 390 mplsTunnelIngressLSRID = 192.0.2.1, 391 mplsTunnelEgressLSRID = 192.0.2.2 392 } 394 7.2. Creating FTN Entries and Applying them to Interfaces 396 The action "redirect packets with source IPv4 address matching 397 192.0.2.63 to an LSP with outgoing ifIndex = 50 and outgoing label = 398 150" in Rule #1 can be implemented by the following entry in 399 mplsFTNTable: 400 { 401 mplsFTNIndex = 1, 402 mplsFTNDescr = "Rule #1", 403 -- source address only 404 mplsFTNMask = 0x80, 405 mplsFTNAddrType = ipv4, 406 mplsFTNSourceAddrMin = 192.0.2.63, 407 mplsFTNSourceAddrMax = 192.0.2.63, 408 mplsFTNActionType = redirectLsp(1), 409 mplsFTNActionPointer = mplsXCLspId.1.2.1.0.1.3 410 } 411 We indicate the LSP to redirect packets to by setting 412 mplsFTNActionPointer to the first accessible columnar object 413 instance in mplsXCEntry that corresponds to this LSP, in this case 414 mplsXCLspId.1.2.1.0.1.3. 416 This action is then activated on "interface ifIndex = 1" by the 417 following entry in mplsFTNMapTable to complete the implementation of 418 Rule #1: 419 { 420 -- apply rule to interface ifIndex = 1 421 mplsFTNMapIndex = 1, 422 -- first FTN entry on this interface 423 mplsFTNPrevIndex = 0, 424 -- index of current entry in mplsFTNTable, i.e. Rule #1 425 mplsFTNMapCurrIndex = 1 426 } 428 The action "redirect packets with destination IPv4 addresses in the 429 range [192.0.2.32, 192.0.2.96] to tunnel #4" in Rule #2 can be 430 implemented by the following entry in mplsFTNTable: 431 { 432 mplsFTNIndex = 2, 433 mplsFTNDescr = "Rule #2", 434 -- destination address only 435 mplsFTNMask = 0x40, 436 mplsFTNAddrType = ipv4, 437 mplsFTNDestAddrMin = 192.0.2.32, 438 mplsFTNDestAddrMax = 192.0.2.96, 439 mplsFTNActionType = redirectTunnel(2), 440 mplsFTNActionPointer = mplsTunnelName.4.0.3221225985.3221225986 441 } 442 where 3221225985 and 3221225986 are the representations of the 443 addresses 192.0.2.1 and 192.0.2.2, respectively, as Unsigned32 (the 444 underlying data type) entities. 446 This rule needs to be activated on "interface ifIndex = 1" after Rule 447 #1 which was previously activated on this interface. This is done by 448 the following entry in mplsFTNMapTable to complete the implementation 449 of Rule #2: 450 { 451 -- apply rule to interface ifIndex = 1 452 mplsFTNMapIndex = 1, 453 -- insert after Rule #1 (mplsFTNIndex = 1) 454 mplsFTNPrevIndex = 1, 455 -- index of current entry in mplsFTNTable, i.e. Rule #2 456 mplsFTNMapCurrIndex = 2 457 } 459 7.3. Mapping an FTN Entry to Multiple Interfaces 461 Suppose we now wish to activate the following rule: 463 Rule #2b: On interface ifIndex = 2 redirect packets with 464 destination IPv4 addresses in the range [192.0.2.32, 192.0.2.96] to 465 tunnel #4 467 Notice that the FEC and corresponding action associated with this 468 rule (i.e. "redirect packets with destination IPv4 addresses in the 469 range [192.0.2.32, 192.0.2.96] to tunnel #4") are the same as that 470 associated with Rule #2. Hence we can reuse the existing entry with 471 mplsFTNIndex = 2 from mplsFTNTable. 473 However, we have to create the following new entry in mplsFTNMapTable 474 to activate this FTN entry as the first one on the interface with 475 ifIndex = 2. 476 { 477 -- apply rule to interface ifIndex = 2 478 mplsFTNMapIndex = 2, 479 -- first FTN entry on this interface 480 mplsFTNPrevIndex = 0, 481 -- index of current entry in mplsFTNTable 482 mplsFTNMapCurrIndex = 2 483 } 485 7.4. Inserting an Entry Into Existing List 487 At a later point suppose that we wish to introduce the following Rule 488 between Rules #1 and #2. 490 Rule #3: On interface ifIndex = 1 redirect all packets with 491 destination IPv4 address matching the prefix 192.0.2.32/28 to 492 tunnel #3 494 where the tunnel we wish to redirect traffic to is represented by the 495 following entry in mplsTunnelTable: 496 { 497 mplsTunnelIndex = 3, 498 -- primary tunnel 499 mplsTunnelInstance = 0, 500 mplsTunnelIngressLSRID = 192.0.2.3, 501 mplsTunnelEgressLSRID = 192.0.2.4 502 } 504 Note that the ordering of the rules on a particular interface is 505 critical since the range of addresses specified in Rule #3 is a 506 subset of the ones specified in Rule #2. 508 Without the linked-list style insertion feature supported by 509 mplsFTNMapTable we would possibly have had to reindex existing 510 entries (or plan for such changes by leaving sufficient gaps between 511 indexes, something that only postpones the problem). With the 512 existing tables we solve this problem by creating the following 513 entries. 515 We implement the phrase "redirect all packets with destination IPv4 516 address matching the prefix 1.4.0.0/16 to tunnel #3" in Rule #3 by 517 creating the following entry in mplsFTNTable: 518 { 519 mplsFTNIndex = 3, 520 mplsFTNDescr = "Rule #3", 521 -- destination address only 522 mplsFTNMask = 0x40, 523 mplsFTNAddrType = ipv4, 524 -- address range equivalent to CIDR prefix 192.0.2.32/28 525 mplsFTNDestAddrMin = 192.0.2.32, 526 mplsFTNDestAddrMax = 192.0.2.47, 527 mplsFTNActionType = redirectTunnel, 528 mplsFTNActionPointer = mplsTunnelName.3.0.3221225987.3221225988 529 } 530 where 3221225987 and 3221225988 are the representations of the 531 addresses 192.0.2.3 and 192.0.2.4, respectively, as Unsigned32 (the 532 underlying data type) entities. 534 We next insert this rule in mplsFTNMapTable just after Rule #1 as 535 follows: 536 { 537 -- apply rule to interface ifIndex = 1 538 mplsFTNMapIndex = 1, 539 -- insert after Rule #1 (mplsFTNIndex = 1) 540 mplsFTNPrevIndex = 1, 541 -- index of current entry in mplsFTNTable i.e. Rule #3 542 mplsFTNMapCurrIndex = 3 543 } 545 After the insertion of Rule #3 in mplsFTNMapTable the 'previous' 546 pointer object mplsFTNMapPrevIndex of the next entry (corresponding 547 to Rule #2) adjusts automatically to point to this entry. 549 Note that, of the existing entries in the table, the only one that is 550 impacted by an insertion operation is the entry on that particular 551 interface immediately after the newly inserted one, if it exists. 552 None of the other entries in mplsFTNMapTable are impacted. For 553 instance, in this particular example, when the entry for Rule #3 was 554 inserted between those for Rules #1 and #2, the entries for Rules #1 555 and #2b were not impacted. 557 7.5. Pictorial Tabular Relationship 559 At this point the relationship between different table entries can be 560 represented pictorially as follows. For each conceptual row instance 561 we show the table that it belongs to along with its indices in 562 parentheses. (Note that various conceptual rows are depicted in a way 563 that is convenient for showing the interrelationships and are not 564 necessarily in lexicographical order.) 566 ifTable, The Interfaces Group MIB [RFC2863]: 567 +-> ifEntry (1) 568 | (ifIndex = 1) 569 | 570 | mplsFTNMapTable: 571 | mplsFTNMapEntry (1.0.1): <--------------------+ 572 +<-- (mplsFTNMapIndex = 1, | 573 | mplsFTNMapPrevIndex = 0, ---> (NULL) | 574 | mplsFTNMapCurrIndex = 1) ------------+ | 575 | | | 576 | mplsFTNMapEntry (1.1.3): <------------------+ | 577 +<-- (mplsFTNMapIndex = 1, | | | 578 | mplsFTNMapPrevIndex = 1, ----------->+ | | 579 | mplsFTNMapCurrIndex = 3) ---------+ | | | 580 | | | | | 581 | mplsFTNMapEntry (1.3.2): <----------------+ | | 582 +<-- (mplsFTNMapIndex = 1, | | | | | 583 mplsFTNMapPrevIndex = 3, -------->+ | | | | 584 mplsFTNMapCurrIndex = 2) ----+ | | | | | 586 | | | | | | 587 mplsFTNTable: | | | | | | 588 mplsFTNEntry (2): | | | | | | 589 +--> (mplsFTNIndex = 2) <----------+ | | | | | 590 | | | | | | 591 | mplsFTNEntry (3): | | | | | 592 | (mplsFTNIndex = 3) <---------------+ | | | | 593 | | | | | 594 | mplsFTNEntry (1): | | | | 595 | (mplsFTNIndex = 1) <------------------+ | | | 596 | | | | 597 | mplsFTNPerfTable: | | | 598 | mplsFTNPerfEntry (1.2): | | | 599 | (mplsFTNPerfIndex = 1, | | | 600 | mplsFTNPerfCurrIndex = 2) --------------+ | | 601 | | | 602 | mplsFTNPerfEntry (1.3): | | 603 | (mplsFTNPerfIndex = 1, | | 604 | mplsFTNPerfCurrIndex = 3) ---------------+ | 605 | | 606 | mplsFTNPerfEntry (1.1): | 607 | (mplsFTNPerfIndex = 1, | 608 | mplsFTNPerfCurrIndex = 1) ------------------+ 609 | 610 | mplsFTNPerfEntry (2.2): 611 | (mplsFTNPerfIndex = 2, 612 | mplsFTNPerfCurrIndex = 2) ------------------+ 613 | | 614 | ifTable, The Interfaces Group MIB [RFC2863]: | 615 +---> ifEntry (2): | 616 | | (ifIndex = 2) | 617 | | | 618 | | mplsFTNMapEntry (2.1.2): <--------------------+ 619 +----- (mplsFTNMapIndex = 2 620 | mplsFTNMapPrevIndex = 0 ---> (NULL) 621 +---- mplsFTNMapCurrIndex = 2) 623 7.6. Deleting an Entry 625 Let us next look at how we can remove the recently applied Rule #3 626 and how the existing conceptual rows behave in this situation. 628 The conceptual row corresponding to the application of Rule #3 to 629 interface ifIndex = 1 has the following index values: mplsFTNMapIndex 630 = 1, mplsFTNMapPrevIndex = 1 and mplsFTNMapCurrIndex = 3. To delete 631 this conceptual row the Network Management Application performs a SET 632 operation setting the object instance mplsFTNMapRowStatus.1.1.3 to 633 the value destroy(6). The agent then destroys this conceptual row. 634 It also automatically adjusts the object instance of 635 mplsFTNMapPrevIndex corresponding to Rule #2 from the value 3 (i.e. 636 pointing to the recently destroyed Rule #3) to the value 1 (i.e. to 637 Rule #1). 639 At this point the rules applied to interface ifIndex = 1 are Rule #1 640 and Rule #2, in that order and the relationship between different 641 table entries can be represented pictorially as follows. 643 ifTable, The Interfaces Group MIB [RFC2863]: 644 +-> ifEntry (1) 645 | (ifIndex = 1) 646 | 647 | mplsFTNMapTable: 648 | mplsFTNMapEntry (1.0.1): <--------------------+ 649 +<-- (mplsFTNMapIndex = 1, | 650 | mplsFTNMapPrevIndex = 0, ---> (NULL) | 651 | mplsFTNMapCurrIndex = 1) ------------+ | 652 | | | 653 | mplsFTNMapEntry (1.1.2): <----------------+ | 654 +<-- (mplsFTNMapIndex = 1, | | | 655 mplsFTNMapPrevIndex = 1, ------------+ | | 656 mplsFTNMapCurrIndex = 2) ----+ | | | 657 | | | | 658 mplsFTNTable: | | | | 659 mplsFTNEntry (2): | | | | 660 +--> (mplsFTNIndex = 2) <----------+ | | | 661 | | | | 662 | mplsFTNEntry (3): | | | 663 | (mplsFTNIndex = 3) | | | 664 | | | | 665 | mplsFTNEntry (1): | | | 666 | (mplsFTNIndex = 1) <------------------+ | | 667 | | | 668 | mplsFTNPerfTable: | | 669 | mplsFTNPerfEntry (1.2): | | 670 | (mplsFTNPerfIndex = 1, | | 671 | mplsFTNPerfCurrIndex = 2) --------------+ | 672 | | 673 | mplsFTNPerfEntry (1.1): | 674 | (mplsFTNPerfIndex = 1, | 675 | mplsFTNPerfCurrIndex = 1) ------------------+ 676 | 677 | mplsFTNPerfEntry (2.2): 678 | (mplsFTNPerfIndex = 2, 679 | mplsFTNPerfCurrIndex = 2) ------------------+ 680 | | 681 | ifTable, The Interfaces Group MIB [RFC2863]: | 682 +---> ifEntry (2): | 683 | | (ifIndex = 2) | 684 | | | 685 | | mplsFTNMapEntry (2.1.2): <--------------------+ 686 +----- (mplsFTNMapIndex = 2 687 | mplsFTNMapPrevIndex = 0 ---> (NULL) 688 +---- mplsFTNMapCurrIndex = 2) 690 Note that the FTN entry for Rule #3 still exists in mplsFTNTable at 691 this point but is not referenced by any conceptual row in 692 mplsFTNMapTable or mplsFTNPerfTable. 694 Also note that the deletion of an entry from mplsFTNMapTable only 695 impacts the entry on that particular interface immediately after the 696 deleted entry, if it exists. None of the other conceptual rows in 697 mplsFTNMapTable are impacted. For instance, in this particular 698 example, when the entry for Rule #3 was deleted, the entries for 699 Rules #1 and #2b were not impacted. 701 8. The Use of RowPointer 703 RowPointer is a textual convention used to identify a conceptual row 704 in a conceptual table in a MIB by pointing to the first accessible 705 object. In this MIB module, in mplsFTNTable, the RowPointer object 706 mplsFTNActionPointer indicates the LSP or TE Tunnel to redirect 707 packets matching an FTN entry to. This object MUST point to the 708 first instance of the first accessible columnar object in the 709 appropriate conceptual row in order to allow the manager to find the 710 appropriate corresponding entry in either MPLS-LSR-STD-MIB [LSRMIB] 711 or MPLS-TE-STD-MIB [TEMIB]. If this object returns zeroDotZero it 712 implies that there is no currently defined action that is associated 713 with that particular FTN entry. 715 9. MPLS-FTN-STD-MIB Definitions 717 MPLS-FTN-STD-MIB DEFINITIONS ::= BEGIN 719 IMPORTS 720 MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Counter64, Integer32 721 FROM SNMPv2-SMI 722 MODULE-COMPLIANCE, OBJECT-GROUP 723 FROM SNMPv2-CONF 724 RowStatus, StorageType, RowPointer, 725 TEXTUAL-CONVENTION, TimeStamp 726 FROM SNMPv2-TC 727 SnmpAdminString 728 FROM SNMP-FRAMEWORK-MIB 729 InterfaceIndexOrZero, 730 ifGeneralInformationGroup, ifCounterDiscontinuityGroup 731 FROM IF-MIB 732 mplsStdMIB 733 FROM MPLS-TC-STD-MIB 734 InetAddressType, InetAddress, InetPortNumber 735 FROM INET-ADDRESS-MIB 736 Dscp 737 FROM DIFFSERV-DSCP-TC 738 ; 740 mplsFTNStdMIB MODULE-IDENTITY 741 LAST-UPDATED "200310201200Z" -- 20 October 2003 12:00:00 GMT 742 ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group" 743 CONTACT-INFO 744 " 745 Thomas D. Nadeau 746 Postal: Cisco Systems, Inc. 747 250 Apollo Drive 748 Chelmsford, MA 01824 749 Tel: +1-978-244-3051 750 Email: tnadeau@cisco.com 752 Cheenu Srinivasan 753 Postal: Bloomberg L.P. 754 499 Park Avenue 755 New York, NY 10022 756 Tel: +1-212-893-3682 757 Email: cheenu@bloomberg.net 759 Arun Viswanathan 760 Postal: Force10 Networks, Inc. 761 1440 McCarthy Blvd 762 Milpitas, CA 95035 763 Tel: +1-408-571-3516 764 Email: arunv@force10networks.com 766 IETF MPLS Working Group email: mpls@uu.net" 768 DESCRIPTION 769 "Copyright (C) The Internet Society (2003). This version of this 770 MIB module is part of RFC xxxx; see the RFC itself for full 771 legal notices. 773 This MIB module contains managed object definitions for 774 specifying FEC to NHLFE (FTN) mappings and corresponding 775 performance for MPLS." 777 -- Revision history. 779 REVISION 780 "200310201200Z" -- 20 October 2003 12:00:00 GMT 782 DESCRIPTION 783 "Initial version issued as part of RFC XXXX." 784 ::= { mplsStdMIB XXX } -- See IANA Considerations section. 785 -- Requested mplsStdMIB sub-ID is 8. 787 -- Textual conventions used in this MIB. 788 MplsFTNEntryIndex ::= TEXTUAL-CONVENTION 789 STATUS current 790 DESCRIPTION 791 "Index for an entry in mplsFTNTable." 792 SYNTAX Unsigned32 (1..4294967295) 794 MplsFTNEntryIndexOrZero ::= TEXTUAL-CONVENTION 795 STATUS current 796 DESCRIPTION 797 "Index for an entry in mplsFTNTable or the special value 798 zero. The value zero is object-specific and must 799 therefore be defined as part of the description of any 800 object which uses this syntax. Examples of the usage 801 of zero might include situations when none or all 802 entries in mplsFTNTable need to be referenced." 803 SYNTAX Unsigned32 (0..4294967295) 805 -- Top-Level Components of this MIB. 807 mplsFTNNotifications OBJECT IDENTIFIER ::= { mplsFTNStdMIB 0 } 808 mplsFTNObjects OBJECT IDENTIFIER ::= { mplsFTNStdMIB 1 } 809 mplsFTNConformance OBJECT IDENTIFIER ::= { mplsFTNStdMIB 2 } 811 -- Next free index in mplsFTNTable. 812 mplsFTNIndexNext OBJECT-TYPE 813 SYNTAX MplsFTNEntryIndexOrZero 814 MAX-ACCESS read-only 815 STATUS current 816 DESCRIPTION 817 "This object contains the next available valid value to 818 be used for mplsFTNIndex when creating entries in the 819 mplsFTNTable. 821 When creating a new conceptual row (configuration 822 entry) in mplsFTNTable with an SNMP SET operation the 823 command generator (Network Management Application) must 824 first issue a management protocol retrieval operation 825 to obtain the current value of this object. 827 If the command responder (agent) does not wish to allow 828 creation of more entries in mplsFTNTable, possibly 829 because of resource exhaustion, this object MUST return 830 a value of 0. 832 If a non-zero value is returned the Network Management 833 Application must determine whether the value is indeed 834 still unused since two Network Management Applications 835 may attempt to create a row simultaneously and use the 836 same value. 838 If it is currently unused and the SET succeeds, the 839 agent MUST change the value of this object to a 840 currently unused non-zero value (according to an 841 implementation specific algorithm) or zero (if no 842 further row creation will be permitted). 844 If the value is in use, however, the SET fails and the 845 Network Management Application must then reread this 846 object to obtain a new usable value." 847 ::= { mplsFTNObjects 1 } 849 -- Last time an object in mplsFTNTable changed. 850 mplsFTNTableLastChanged OBJECT-TYPE 851 SYNTAX TimeStamp 852 MAX-ACCESS read-only 853 STATUS current 854 DESCRIPTION 855 "Indicates the last time an entry was added, deleted or 856 modified in mplsFTNTable. Management stations should 857 consult this object to determine if mplsFTNTable 858 requires their attention. This object is particularly 859 useful for applications performing a retrieval on 860 mplsFTNTable to ensure that the table is not modified 861 during the retrieval operation." 862 ::= { mplsFTNObjects 2 } 864 -- Table of FTN entries. 865 mplsFTNTable OBJECT-TYPE 866 SYNTAX SEQUENCE OF MplsFTNEntry 867 MAX-ACCESS not-accessible 868 STATUS current 869 DESCRIPTION 870 "This table contains the currently defined FTN entries. 871 This table allows FEC to NHLFE mappings to be 872 specified. Each entry in this table defines a rule to 873 be applied to incoming packets (on interfaces that the 874 FTN entry is activated on using mplsFTNMapTable) and an 875 action to be taken on matching packets 876 (mplsFTNActionPointer). 878 This table supports 6-tuple matching rules based on one 879 or more of source address range, destination address 880 range, source port range, destination port range, IPv4 881 Protocol field or IPv6 next-header field and the 882 DiffServ Code Point (DSCP) to be specified. 884 The action pointer points either to instance of 885 mplsXCEntry in MPLS-LSR-STD-MIB when the NHLFE is a non- 886 TE LSP, or to an instance of mplsTunnelEntry in the 887 MPLS-TE-STD-MIB when the NHLFE is an originating TE 888 tunnel." 889 REFERENCE 890 "J. Postel, Internet Protocol, RFC 791, STD 5, September 891 1981 893 Deering, S., and R. Hinden, Internet Protocol, Version 894 6 (IPv6) Specification, RFC 2460, December 1998 896 Nichols, K, Blake, S., Baker, F. and D. Black, 897 Definition of the Differentiated Services Field (DS 898 Field) in the IPv4 and IPv6 Headers, RFC 2474, December 899 1998 901 Srinivasan, C., A. Viswanathan, and T. Nadeau, MPLS 902 Label Switch Router Management Information Base, draft- 903 ietf-mpls-lsr-mib-12.txt 905 Srinivasan, C., A. Viswanathan, and T. Nadeau, MPLS 906 Traffic Engineering Management Information Base, draft- 907 ietf-mpls-te-mib-12.txt" 908 ::= { mplsFTNObjects 3 } 910 mplsFTNEntry OBJECT-TYPE 911 SYNTAX MplsFTNEntry 912 MAX-ACCESS not-accessible 913 STATUS current 914 DESCRIPTION 915 "Each entry represents one FTN entry which defines a 916 rule to compare incoming packets with and an action to 917 be taken on matching packets." 918 INDEX { mplsFTNIndex } 919 ::= { mplsFTNTable 1 } 921 MplsFTNEntry ::= SEQUENCE { 922 mplsFTNIndex MplsFTNEntryIndex, 923 mplsFTNRowStatus RowStatus, 924 mplsFTNDescr SnmpAdminString, 925 mplsFTNMask BITS, 926 mplsFTNAddrType InetAddressType, 927 mplsFTNSourceAddrMin InetAddress, 928 mplsFTNSourceAddrMax InetAddress, 929 mplsFTNDestAddrMin InetAddress, 930 mplsFTNDestAddrMax InetAddress, 931 mplsFTNSourcePortMin InetPortNumber, 932 mplsFTNSourcePortMax InetPortNumber, 933 mplsFTNDestPortMin InetPortNumber, 934 mplsFTNDestPortMax InetPortNumber, 935 mplsFTNProtocol Integer32, 936 mplsFTNDscp Dscp, 937 mplsFTNActionType INTEGER, 938 mplsFTNActionPointer RowPointer, 939 mplsFTNStorageType StorageType 940 } 942 mplsFTNIndex OBJECT-TYPE 943 SYNTAX MplsFTNEntryIndex 944 MAX-ACCESS not-accessible 945 STATUS current 946 DESCRIPTION 947 "This is the unique index for a conceptual row in 948 mplsFTNTable. 950 To create a new conceptual row in mplsFTNTable a 951 Network Management Application SHOULD retrieve the 952 current value of mplsFTNIndexNext to determine the next 953 valid available value of mplsFTNIndex." 954 ::= { mplsFTNEntry 1 } 956 mplsFTNRowStatus OBJECT-TYPE 957 SYNTAX RowStatus 958 MAX-ACCESS read-create 959 STATUS current 960 DESCRIPTION 961 "Used for controlling the creation and deletion of this 962 row. All writeable objects in this row may be modified 963 at any time. If a Network Management Application 964 attempts to delete a conceptual row by setting this 965 object to 'destroy' and there are one or more entries 966 in mplsFTNMapTable pointing to the row (i.e. when 967 mplsFTNIndex of the conceptual row being deleted is 968 equal to mplsFTNMapCurrIndex for one or more entries in 969 mplsFTNMapTable), the agent MUST also destroy the 970 corresponding entries in mplsFTNMapTable." 971 ::= { mplsFTNEntry 2 } 973 mplsFTNDescr OBJECT-TYPE 974 SYNTAX SnmpAdminString 975 MAX-ACCESS read-create 976 STATUS current 977 DESCRIPTION 978 "The description of this FTN entry. Since the index for 979 this table has no particular significance or meaning, 980 this object should contain some meaningful text that an 981 operator could use to further distinguish entries in 982 this table." 983 ::= { mplsFTNEntry 3 } 985 mplsFTNMask OBJECT-TYPE 986 SYNTAX BITS { 987 sourceAddr(0), 988 destAddr(1), 989 sourcePort(2), 990 destPort(3), 991 protocol(4), 992 dscp(5) 993 } 994 MAX-ACCESS read-create 995 STATUS current 996 DESCRIPTION 997 "This bit map indicates which of the fields described 998 next, namely source address range, destination address 999 range, source port range, destination port range, IPv4 1000 Protocol field or IPv6 next-header field and 1001 Differentiated Services Code Point (DSCP) is active for 1002 this FTN entry. If a particular bit is set to zero then 1003 the corresponding field in the packet MUST be ignored 1004 for comparison purposes." 1005 ::= { mplsFTNEntry 4 } 1007 mplsFTNAddrType OBJECT-TYPE 1008 SYNTAX InetAddressType 1009 MAX-ACCESS read-create 1010 STATUS current 1011 DESCRIPTION 1012 "This object determines the type of address contained in 1013 the source and destination address objects 1014 (mplsFTNSourceAddrMin, mplsFTNSourceAddrMax, 1015 mplsFTNDestAddrMin and mplsFTNDestAddrMax) of a 1016 conceptual row. 1018 This object MUST NOT be set to unknown(0) when 1019 mplsFTNMask has bit positions sourceAddr(0) or 1020 destAddr(1) set to one. 1022 When both these bit positions of mplsFTNMask are set to 1023 zero the value of mplsFTNAddrType SHOULD be set to 1024 unknown(0) and the corresponding source and destination 1025 address objects SHOULD be set to zero-length strings." 1026 ::= { mplsFTNEntry 5 } 1028 mplsFTNSourceAddrMin OBJECT-TYPE 1029 SYNTAX InetAddress 1030 MAX-ACCESS read-create 1031 STATUS current 1032 DESCRIPTION 1033 "The lower end of the source address range. The type of 1034 this object is determined by the corresponding 1035 mplsFTNAddrType object." 1036 ::= { mplsFTNEntry 6 } 1038 mplsFTNSourceAddrMax OBJECT-TYPE 1039 SYNTAX InetAddress 1040 MAX-ACCESS read-create 1041 STATUS current 1042 DESCRIPTION 1043 "The upper end of the source address range. The type of 1044 this object is determined by the corresponding 1045 mplsFTNAddrType object." 1046 ::= { mplsFTNEntry 7 } 1048 mplsFTNDestAddrMin OBJECT-TYPE 1049 SYNTAX InetAddress 1050 MAX-ACCESS read-create 1051 STATUS current 1052 DESCRIPTION 1053 "The lower end of the destination address range. The 1054 type of this object is determined by the corresponding 1055 mplsFTNAddrType object." 1056 ::= { mplsFTNEntry 8 } 1058 mplsFTNDestAddrMax OBJECT-TYPE 1059 SYNTAX InetAddress 1060 MAX-ACCESS read-create 1061 STATUS current 1062 DESCRIPTION 1063 "The higher end of the destination address range. The 1064 type of this object is determined by the corresponding 1065 mplsFTNAddrType object." 1066 ::= { mplsFTNEntry 9 } 1068 mplsFTNSourcePortMin OBJECT-TYPE 1069 SYNTAX InetPortNumber 1070 MAX-ACCESS read-create 1071 STATUS current 1072 DESCRIPTION 1073 "The lower end of the source port range." 1074 DEFVAL { 0 } 1075 ::= { mplsFTNEntry 10 } 1077 mplsFTNSourcePortMax OBJECT-TYPE 1078 SYNTAX InetPortNumber 1079 MAX-ACCESS read-create 1080 STATUS current 1081 DESCRIPTION 1082 "The higher end of the source port range " 1083 DEFVAL { 65535 } 1084 ::= { mplsFTNEntry 11 } 1086 mplsFTNDestPortMin OBJECT-TYPE 1087 SYNTAX InetPortNumber 1088 MAX-ACCESS read-create 1089 STATUS current 1090 DESCRIPTION 1091 "The lower end of the destination port range." 1092 DEFVAL { 0 } 1093 ::= { mplsFTNEntry 12 } 1095 mplsFTNDestPortMax OBJECT-TYPE 1096 SYNTAX InetPortNumber 1097 MAX-ACCESS read-create 1098 STATUS current 1099 DESCRIPTION 1100 "The higher end of the destination port range." 1101 DEFVAL { 65535 } 1102 ::= { mplsFTNEntry 13 } 1104 mplsFTNProtocol OBJECT-TYPE 1105 SYNTAX Integer32 (0..255) 1106 MAX-ACCESS read-create 1107 STATUS current 1108 DESCRIPTION 1109 "The IP protocol to match against the IPv4 protocol 1110 number or IPv6 Next-Header number in the packet. A 1111 value of 255 means match all. Note that the protocol 1112 number of 255 is reserved by IANA, and Next-Header 1113 number of 0 is used in IPv6." 1114 DEFVAL { 255 } 1115 ::= { mplsFTNEntry 14 } 1117 mplsFTNDscp OBJECT-TYPE 1118 SYNTAX Dscp 1119 MAX-ACCESS read-create 1120 STATUS current 1121 DESCRIPTION 1122 "The contents of the DSCP field." 1123 REFERENCE 1124 "Nichols, K., Blake, S., Baker, F. and D. Black, 1125 Definition of the Differentiated Services Field (DS 1126 Field) in the IPv4 and IPv6 Headers, RFC 2474, December 1127 1998." 1128 ::= { mplsFTNEntry 15 } 1130 mplsFTNActionType OBJECT-TYPE 1131 SYNTAX INTEGER { 1132 redirectLsp(1), -- redirect into LSP 1133 redirectTunnel(2) -- redirect into tunnel 1134 } 1135 MAX-ACCESS read-create 1136 STATUS current 1137 DESCRIPTION 1138 "The type of action to be taken on packets matching this 1139 FTN entry." 1140 ::= { mplsFTNEntry 16 } 1142 mplsFTNActionPointer OBJECT-TYPE 1143 SYNTAX RowPointer 1144 MAX-ACCESS read-create 1145 STATUS current 1146 DESCRIPTION 1147 "If mplsFTNActionType is redirectLsp(1), then this 1148 object MUST contain zeroDotZero or point to a instance 1149 of mplsXCEntry indicating the LSP to redirect matching 1150 packets to. 1152 If mplsFTNActionType is redirectTunnel(2), then this 1153 object MUST contain zeroDotZero or point to a instance 1154 of mplsTunnelEntry indicating the MPLS TE tunnel to 1155 redirect matching packets to. 1157 If this object points to a conceptual row instance in a 1158 table consistent with mplsFTNActionType but this 1159 instance does not currently exist then no action will 1160 be taken on packets matching such an FTN entry till 1161 this instance comes into existence. 1163 If this object contains zeroDotZero then no action will 1164 be taken on packets matching such an FTN entry till it 1165 is populated with a valid pointer consistent with the 1166 value of mplsFTNActionType as explained above." 1167 ::= { mplsFTNEntry 17 } 1169 mplsFTNStorageType OBJECT-TYPE 1170 SYNTAX StorageType 1171 MAX-ACCESS read-create 1172 STATUS current 1173 DESCRIPTION 1174 "The storage type for this FTN entry. Conceptual rows 1175 having the value 'permanent' need not allow write- 1176 access to any columnar objects in the row." 1177 DEFVAL { nonVolatile } 1178 ::= { mplsFTNEntry 18 } 1180 -- End of mplsFTNTable. 1182 -- Last time an object in mplsFTNMapTable changed. 1183 mplsFTNMapTableLastChanged OBJECT-TYPE 1184 SYNTAX TimeStamp 1185 MAX-ACCESS read-only 1186 STATUS current 1187 DESCRIPTION 1188 "Indicates the last time an entry was added, deleted or 1189 modified in mplsFTNMapTable. Management stations should 1190 consult this object to determine if the table requires 1191 their attention. This object is particularly useful 1192 for applications performing a retrieval on 1193 mplsFTNMapTable to ensure that the table is not 1194 modified during the retrieval operation." 1195 ::= { mplsFTNObjects 4 } 1197 -- FTN to interface mapping table. 1198 mplsFTNMapTable OBJECT-TYPE 1199 SYNTAX SEQUENCE OF MplsFTNMapEntry 1200 MAX-ACCESS not-accessible 1201 STATUS current 1202 DESCRIPTION 1203 "This table contains objects which provide the 1204 capability to apply or map FTN rules as defined by 1205 entries in mplsFTNTable to specific interfaces in the 1206 system. FTN rules are compared with incoming packets 1207 in the order in which they are applied on an interface. 1209 The indexing structure of mplsFTNMapTable is as 1210 follows. 1212 - mplsFTNMapIndex indicates the interface to which the 1213 rule is being applied. A value of 0 represents the 1214 application of the rule to all interfaces. 1216 - mplsFTNMapPrevIndex specifies the rule on the 1217 interface prior to the one being applied. A value of 1218 0 specifies that the rule is being inserted at the 1219 head of the list of rules currently applied to the 1220 interface. 1222 - mplsFTNMapCurrIndex is the index in mplsFTNTable 1223 corresponding to the rule being applied. 1225 This indexing structure makes the entries in the table 1226 behave like items in a linked-list. The object 1227 mplsFTNMapPrevIndex in each conceptual row is a pointer 1228 to the previous entry that is applied to a particular 1229 interface. This allows a new entry to be 'inserted' at 1230 an arbitrary position in a list of entries currently 1231 applied to an interface. This object is self- 1232 adjusting, i.e. its value is automatically adjusted by 1233 the agent, if necessary, after an insertion or deletion 1234 operation. 1236 Using this linked-list structure, one can retrieve FTN 1237 entries in the order of application on a per-interface 1238 basis as follows: 1240 - To determine the first FTN entry on an interface 1241 with index ifIndex perform a GETNEXT retrieval 1242 operation on mplsFTNMapRowStatus.ifIndex.0.0; the 1243 returned object, if one exists, is (say) 1244 mplsFTNMapRowStatus.ifIndex.0.n (mplsFTNMapRowStatus 1245 is the first accessible columnar object in the 1246 conceptual row). Then the index of the first FTN 1247 entry applied on this interface is n. 1249 - To determine the FTN entry applied to an interface 1250 after the one indexed by n perform a GETNEXT 1251 retrieval operation on 1252 mplsFTNMapRowStatus.ifIndex.n.0. If such an entry 1253 exists the returned object would be of the form 1254 mplsFTNMapRowStatus.ifIndex.n.m. Then the index of 1255 the next FTN entry applied on this interface is m. 1257 - If the FTN entry indexed by n is the last entry 1258 applied to the interface with index ifIndex then the 1259 object returned would either be: 1261 1.mplsFTNMapRowStatus.ifIndexNext.0.k, where 1262 ifIndexNext is the index of the next interface in 1263 ifTable to which an FTN entry has been applied, in 1264 which case k is the index of the first FTN entry 1265 applied to the interface with index ifIndexNext; 1267 or: 1269 2.mplsFTNMapStorageType.firstIfIndex.0.p, if there 1270 are no more entries in mplsFTNMapTable, where 1271 firstIfIndex is the first entry in ifTable to 1272 which an FTN entry has been mapped. 1274 Use the above steps to retrieve all the applied FTN 1275 entries on a per-interface basis in application order. 1276 Note that the number of retrieval operations is the 1277 same as the number of applied FTN entries (i.e. the 1278 minimum number of GETNEXT operations needed using any 1279 indexing scheme). 1281 Agents MUST NOT allow the same FTN entry as specified 1282 by mplsFTNMapCurrIndex to be applied multiple times to 1283 the same interface. 1285 Agents MUST NOT allow the creation of rows in this 1286 table until the corresponding rows are created in the 1287 mplsFTNTable. 1289 If a row in mplsFTNTable is destroyed, the agent MUST 1290 destroy the corresponding entries (i.e. ones with a 1291 matching value of mplsFTNCurrIndex) in this table as 1292 well." 1293 ::= { mplsFTNObjects 5 } 1295 mplsFTNMapEntry OBJECT-TYPE 1296 SYNTAX MplsFTNMapEntry 1297 MAX-ACCESS not-accessible 1298 STATUS current 1299 DESCRIPTION 1300 "Each conceptual row represents the application of an 1301 FTN rule at a specific position in the list of FTN 1302 rules applied on an interface. " 1303 INDEX { 1304 mplsFTNMapIndex, 1305 mplsFTNMapPrevIndex, 1306 mplsFTNMapCurrIndex 1307 } 1308 ::= { mplsFTNMapTable 1 } 1310 MplsFTNMapEntry ::= SEQUENCE { 1311 mplsFTNMapIndex InterfaceIndexOrZero, 1312 mplsFTNMapPrevIndex MplsFTNEntryIndexOrZero, 1313 mplsFTNMapCurrIndex MplsFTNEntryIndex, 1314 mplsFTNMapRowStatus RowStatus, 1315 mplsFTNMapStorageType StorageType 1316 } 1318 mplsFTNMapIndex OBJECT-TYPE 1319 SYNTAX InterfaceIndexOrZero 1320 MAX-ACCESS not-accessible 1321 STATUS current 1322 DESCRIPTION 1323 "The interface index that this FTN entry is being 1324 applied to. A value of zero indicates an entry that is 1325 applied all interfaces. 1327 Entries mapped to an interface by specifying its (non- 1328 zero) interface index in mplsFTNMapIndex are applied 1329 ahead of entries with mplsFTNMapIndex equal to zero." 1330 ::= { mplsFTNMapEntry 1 } 1332 mplsFTNMapPrevIndex OBJECT-TYPE 1333 SYNTAX MplsFTNEntryIndexOrZero 1334 MAX-ACCESS not-accessible 1335 STATUS current 1336 DESCRIPTION 1337 "The index of the previous FTN entry that was applied to 1338 this interface. The special value zero indicates that 1339 this should be the first FTN entry in the list." 1340 ::= { mplsFTNMapEntry 2 } 1342 mplsFTNMapCurrIndex OBJECT-TYPE 1343 SYNTAX MplsFTNEntryIndex 1344 MAX-ACCESS not-accessible 1345 STATUS current 1346 DESCRIPTION 1347 "Index of the current FTN entry that is being applied to 1348 this interface." 1349 ::= { mplsFTNMapEntry 3 } 1351 mplsFTNMapRowStatus OBJECT-TYPE 1352 SYNTAX RowStatus { 1353 active(1), 1354 createAndGo(4), 1355 destroy(6) 1356 } 1357 MAX-ACCESS read-create 1358 STATUS current 1359 DESCRIPTION 1360 "Used for controlling the creation and deletion of this 1361 row. 1363 All writable objects in this row may be modified at any 1364 time. 1366 If a conceptual row in mplsFTNMapTable points to a 1367 conceptual row in mplsFTNTable which is subsequently 1368 deleted, the corresponding conceptual row in 1369 mplsFTNMapTable MUST also be deleted by the agent." 1370 ::= { mplsFTNMapEntry 4 } 1372 mplsFTNMapStorageType OBJECT-TYPE 1373 SYNTAX StorageType 1374 MAX-ACCESS read-create 1375 STATUS current 1376 DESCRIPTION 1377 "The storage type for this entry. Conceptual rows 1378 having the value 'permanent' need not allow write- 1379 access to any columnar objects in this row." 1380 DEFVAL { nonVolatile } 1381 ::= { mplsFTNMapEntry 5 } 1383 -- End of mplsFTNMapTable 1385 -- FTN entry performance table 1387 mplsFTNPerfTable OBJECT-TYPE 1388 SYNTAX SEQUENCE OF MplsFTNPerfEntry 1389 MAX-ACCESS not-accessible 1390 STATUS current 1391 DESCRIPTION 1392 "This table contains performance statistics on FTN 1393 entries on a per-interface basis." 1394 ::= { mplsFTNObjects 6 } 1396 mplsFTNPerfEntry OBJECT-TYPE 1397 SYNTAX MplsFTNPerfEntry 1398 MAX-ACCESS not-accessible 1399 STATUS current 1400 DESCRIPTION 1401 "Each entry contains performance information for the 1402 specified interface and an FTN entry mapped to this 1403 interface." 1404 INDEX { mplsFTNPerfIndex, mplsFTNPerfCurrIndex } 1405 ::= { mplsFTNPerfTable 1 } 1407 MplsFTNPerfEntry ::= SEQUENCE { 1408 mplsFTNPerfIndex InterfaceIndexOrZero, 1409 mplsFTNPerfCurrIndex MplsFTNEntryIndex, 1410 mplsFTNPerfMatchedPackets Counter64, 1411 mplsFTNPerfMatchedOctets Counter64, 1412 mplsFTNPerfDiscontinuityTime TimeStamp 1413 } 1415 mplsFTNPerfIndex OBJECT-TYPE 1416 SYNTAX InterfaceIndexOrZero 1417 MAX-ACCESS not-accessible 1418 STATUS current 1419 DESCRIPTION 1420 "The interface index of an interface that an FTN entry 1421 has been applied/mapped to. Each instance of this 1422 object corresponds to an instance of mplsFTNMapIndex." 1423 ::= { mplsFTNPerfEntry 1 } 1425 mplsFTNPerfCurrIndex OBJECT-TYPE 1426 SYNTAX MplsFTNEntryIndex 1427 MAX-ACCESS not-accessible 1428 STATUS current 1429 DESCRIPTION 1430 "Index of an FTN entry that has been applied/mapped to 1431 the specified interface. Each instance of this object 1432 corresponds to an instance of mplsFTNMapCurrIndex." 1433 ::= { mplsFTNPerfEntry 2 } 1435 mplsFTNPerfMatchedPackets OBJECT-TYPE 1436 SYNTAX Counter64 1437 MAX-ACCESS read-only 1438 STATUS current 1439 DESCRIPTION 1440 "Number of packets that matched the specified FTN entry 1441 if it is applied/mapped to the specified interface. 1442 Discontinuities in the value of this counter can occur 1443 at re-initialization of the management system, and at 1444 other times as indicated by the value of 1445 mplsFTNDiscontinuityTime." 1446 ::= { mplsFTNPerfEntry 3 } 1448 mplsFTNPerfMatchedOctets OBJECT-TYPE 1449 SYNTAX Counter64 1450 MAX-ACCESS read-only 1451 STATUS current 1452 DESCRIPTION 1453 "Number of octets that matched the specified FTN entry 1454 if it is applied/mapped to the specified interface. 1455 Discontinuities in the value of this counter can occur 1456 at re-initialization of the management system, and at 1457 other times as indicated by the value of 1458 mplsFTNDiscontinuityTime." 1459 ::= { mplsFTNPerfEntry 4 } 1461 mplsFTNPerfDiscontinuityTime OBJECT-TYPE 1462 SYNTAX TimeStamp 1463 MAX-ACCESS read-only 1464 STATUS current 1465 DESCRIPTION 1466 "The value of sysUpTime on the most recent occasion at 1467 which any one or more of this entry's counters suffered 1468 a discontinuity. If no such discontinuities have 1469 occurred since the last re-initialization of the local 1470 management subsystem, then this object contains a zero 1471 value." 1472 ::= { mplsFTNPerfEntry 5 } 1474 -- End of mplsFTNPerfTable 1476 -- Module compliance. 1478 -- Top level object IDs. 1479 mplsFTNGroups 1480 OBJECT IDENTIFIER ::= { mplsFTNConformance 1 } 1481 mplsFTNCompliances 1482 OBJECT IDENTIFIER ::= { mplsFTNConformance 2 } 1484 -- Compliance requirement for fully compliant implementations. 1485 mplsFTNModuleFullCompliance MODULE-COMPLIANCE 1486 STATUS current 1487 DESCRIPTION 1488 "Compliance statement for agents that provide full 1489 support for MPLS-FTN-STD-MIB." 1491 MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863. 1492 MANDATORY-GROUPS { 1493 ifGeneralInformationGroup, 1494 ifCounterDiscontinuityGroup 1495 } 1497 MODULE -- This module. 1498 MANDATORY-GROUPS { 1499 mplsFTNRuleGroup, 1500 mplsFTNMapGroup, 1501 mplsFTNPerfGroup 1502 } 1504 OBJECT mplsFTNAddrType 1505 SYNTAX InetAddressType { ipv4(1), ipv6(2) } 1506 DESCRIPTION 1507 "An implementation is only required to support IPv4 1508 and/or IPv6 addresses. An implementation is only 1509 required to support the address types that are actually 1510 supported on the LSR." 1512 OBJECT mplsFTNSourceAddrMin 1513 SYNTAX InetAddress (SIZE (4 | 20)) 1514 DESCRIPTION 1515 "An implementation is only required to support IPv4 1516 and/or IPv6 addresses. An implementation is only 1517 required to support the address types that are actually 1518 supported on the LSR." 1520 OBJECT mplsFTNSourceAddrMax 1521 SYNTAX InetAddress (SIZE (4 | 20)) 1522 DESCRIPTION 1523 "An implementation is only required to support IPv4 1524 and/or IPv6 addresses. An implementation is only 1525 required to support the address types that are actually 1526 supported on the LSR." 1528 OBJECT mplsFTNDestAddrMin 1529 SYNTAX InetAddress (SIZE (4 | 20)) 1530 DESCRIPTION 1531 "An implementation is only required to support IPv4 1532 and/or IPv6 addresses. An implementation is only 1533 required to support the address types that are actually 1534 supported on the LSR." 1536 OBJECT mplsFTNDestAddrMax 1537 SYNTAX InetAddress (SIZE (4 | 20)) 1538 DESCRIPTION 1539 "An implementation is only required to support IPv4 1540 and/or IPv6 addresses. An implementation is only 1541 required to support the address types that are actually 1542 supported on the LSR." 1544 ::= { mplsFTNCompliances 1 } 1546 -- Compliance requirement for read-only implementations. 1547 mplsFTNModuleReadOnlyCompliance MODULE-COMPLIANCE 1548 STATUS current 1549 DESCRIPTION 1550 "Compliance requirement for implementations that only 1551 provide read-only support for MPLS-FTN-STD-MIB. Such 1552 devices can then be monitored but cannot be configured 1553 using this MIB module." 1555 MODULE IF-MIB -- The interfaces Group MIB, RFC 2863 1556 MANDATORY-GROUPS { 1557 ifGeneralInformationGroup, 1558 ifCounterDiscontinuityGroup 1559 } 1561 MODULE -- This module 1562 MANDATORY-GROUPS { 1563 mplsFTNRuleGroup, 1564 mplsFTNMapGroup, 1565 mplsFTNPerfGroup 1566 } 1568 OBJECT mplsFTNIndexNext 1569 MIN-ACCESS not-accessible 1570 DESCRIPTION 1571 "This object is not needed when mplsFTNTable is 1572 implemented as read-only." 1574 OBJECT mplsFTNRowStatus 1575 SYNTAX RowStatus { active(1) } 1576 MIN-ACCESS read-only 1577 DESCRIPTION 1578 "Write access is not required, and active is the only 1579 status that needs to be supported." 1581 OBJECT mplsFTNDescr 1582 MIN-ACCESS read-only 1583 DESCRIPTION 1584 "Write access is not required." 1586 OBJECT mplsFTNMask 1587 MIN-ACCESS read-only 1588 DESCRIPTION 1589 "Write access is not required." 1591 OBJECT mplsFTNAddrType 1592 SYNTAX InetAddressType { ipv4(1), ipv6(2) } 1593 MIN-ACCESS read-only 1594 DESCRIPTION 1595 "Write access is not required. An implementation is only 1596 required to support IPv4 and IPv6 addresses." 1598 OBJECT mplsFTNSourceAddrMin 1599 SYNTAX InetAddress (SIZE (4 | 20)) 1600 MIN-ACCESS read-only 1601 DESCRIPTION 1602 "Write access is not required. An implementation is only 1603 required to support IPv4 and IPv6 addresses." 1605 OBJECT mplsFTNSourceAddrMax 1606 SYNTAX InetAddress (SIZE (4 | 20)) 1607 MIN-ACCESS read-only 1608 DESCRIPTION 1609 "Write access is not required. An implementation is only 1610 required to support IPv4 and IPv6 addresses." 1612 OBJECT mplsFTNDestAddrMin 1613 SYNTAX InetAddress (SIZE (4 | 20)) 1614 MIN-ACCESS read-only 1615 DESCRIPTION 1616 "Write access is not required. An implementation is only 1617 required to support IPv4 and IPv6 addresses." 1619 OBJECT mplsFTNDestAddrMax 1620 SYNTAX InetAddress (SIZE (4 | 20)) 1621 MIN-ACCESS read-only 1622 DESCRIPTION 1623 "Write access is not required. An implementation is only 1624 required to support IPv4 and IPv6 addresses." 1626 OBJECT mplsFTNSourcePortMin 1627 MIN-ACCESS read-only 1628 DESCRIPTION 1629 "Write access is not required." 1631 OBJECT mplsFTNSourcePortMax 1632 MIN-ACCESS read-only 1633 DESCRIPTION 1634 "Write access is not required." 1636 OBJECT mplsFTNDestPortMin 1637 MIN-ACCESS read-only 1638 DESCRIPTION 1639 "Write access is not required." 1641 OBJECT mplsFTNDestPortMax 1642 MIN-ACCESS read-only 1643 DESCRIPTION 1644 "Write access is not required." 1646 OBJECT mplsFTNProtocol 1647 MIN-ACCESS read-only 1648 DESCRIPTION 1649 "Write access is not required." 1651 OBJECT mplsFTNActionType 1652 MIN-ACCESS read-only 1653 DESCRIPTION 1654 "Write access is not required." 1656 OBJECT mplsFTNActionPointer 1657 MIN-ACCESS read-only 1658 DESCRIPTION 1659 "Write access is not required." 1661 OBJECT mplsFTNDscp 1662 MIN-ACCESS read-only 1663 DESCRIPTION 1664 "Write access is not required." 1666 OBJECT mplsFTNStorageType 1667 MIN-ACCESS read-only 1668 DESCRIPTION 1669 "Write access is not required." 1671 OBJECT mplsFTNMapRowStatus 1672 SYNTAX RowStatus { active(1) } 1673 MIN-ACCESS read-only 1674 DESCRIPTION 1675 "Write access is not required, and active(1) is the only 1676 status that needs to be supported." 1678 OBJECT mplsFTNMapStorageType 1679 MIN-ACCESS read-only 1680 DESCRIPTION 1681 "Write access is not required." 1683 ::= { mplsFTNCompliances 2 } 1685 -- Units of conformance. 1686 mplsFTNRuleGroup OBJECT-GROUP 1687 OBJECTS { 1688 mplsFTNIndexNext, 1689 mplsFTNTableLastChanged, 1690 mplsFTNRowStatus, 1691 mplsFTNDescr, 1692 mplsFTNMask, 1693 mplsFTNAddrType, 1694 mplsFTNSourceAddrMin, 1695 mplsFTNSourceAddrMax, 1696 mplsFTNDestAddrMin, 1697 mplsFTNDestAddrMax, 1698 mplsFTNSourcePortMin, 1699 mplsFTNSourcePortMax, 1700 mplsFTNDestPortMin, 1701 mplsFTNDestPortMax, 1702 mplsFTNProtocol, 1703 mplsFTNActionType, 1704 mplsFTNActionPointer, 1705 mplsFTNDscp, 1706 mplsFTNStorageType 1707 } 1708 STATUS current 1709 DESCRIPTION 1710 "Collection of objects that implement MPLS FTN rules." 1711 ::= { mplsFTNGroups 1 } 1713 mplsFTNMapGroup OBJECT-GROUP 1714 OBJECTS { 1715 mplsFTNMapTableLastChanged, 1716 mplsFTNMapRowStatus, 1717 mplsFTNMapStorageType 1718 } 1719 STATUS current 1720 DESCRIPTION 1721 "Collection of objects that implement activation of MPLS 1722 FTN entries on interfaces." 1723 ::= { mplsFTNGroups 2 } 1725 mplsFTNPerfGroup OBJECT-GROUP 1726 OBJECTS { 1727 mplsFTNPerfMatchedPackets, 1728 mplsFTNPerfMatchedOctets, 1729 mplsFTNPerfDiscontinuityTime 1730 } 1731 STATUS current 1732 DESCRIPTION 1733 "Collection of objects providing MPLS FTN performance 1734 information." 1735 ::= { mplsFTNGroups 3 } 1737 END 1739 10. Security Considerations 1741 This MIB module can be used to configure LSRs to redirect non-MPLS 1742 traffic into an MPLS cloud. As such, improper manipulation of the 1743 objects represented in this MIB module may result in traffic being 1744 redirected to unintended destinations, potentially resulting in 1745 denial of service to end-users. 1747 There are a number of management objects defined in this MIB module 1748 with a MAX-ACCESS clause of read-write and/or read-create. Such 1749 objects may be considered sensitive or vulnerable in some network 1750 environments. The support for SET operations in a non-secure 1751 environment without proper protection can have a negative effect on 1752 network operations. These are the tables and objects and their 1753 sensitivity/vulnerability: 1755 - mplsFTNTable and mplsFTNMapTable can be used to create packet 1756 matching rules for classifying IPv4 or IPv6 traffic and 1757 redirecting matched packets into the MPLS cloud. Modifying 1758 objects in these tables can result in misdirection of traffic and 1759 potential denial of service to end-users. It may also result in 1760 traffic which was intended to be redirected into the MPLS cloud 1761 being routed through the IP network instead, potentially 1762 resulting in degradation of service quality or outright denial of 1763 service. 1765 Some of the readable objects in this MIB module (i.e., objects with a 1766 MAX-ACCESS other than not-accessible) may be considered sensitive or 1767 vulnerable in some network environments. It is thus important to 1768 control even GET and/or NOTIFY access to these objects and possibly 1769 to even encrypt the values of these objects when sending them over 1770 the network via SNMP. These are the tables and objects and their 1771 sensitivity/vulnerability: 1773 - mplsFTNPerfTable provides counters for monitoring the performance 1774 of packet classification rules defined in mplsFTNTable and 1775 mplsFTNMapTable. Unauthorized read access to objects in these 1776 tables may be used to gain traffic flow information. 1778 SNMP versions prior to SNMPv3 did not include adequate security. 1779 Even if the network itself is secure (for example by using IPSec), 1780 even then, there is no control as to who on the secure network is 1781 allowed to access and GET/SET (read/change/create/delete) the objects 1782 in this MIB module. 1784 It is RECOMMENDED that implementers consider the security features as 1785 provided by the SNMPv3 framework (see [RFC3410], section 8), 1786 including full support for the SNMPv3 cryptographic mechanisms (for 1787 authentication and privacy). 1789 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1790 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1791 enable cryptographic security. It is then a customer/operator 1792 responsibility to ensure that the SNMP entity giving access to an 1793 instance of this MIB module is properly configured to give access to 1794 the objects only to those principals (users) that have legitimate 1795 rights to indeed GET or SET (change/create/delete) them. 1797 11. IANA Considerations 1799 As described in [MPLSMGMT] and as requested in [TCMIB], MPLS related 1800 standards-track MIB modules should be rooted under the mplsStdMIB 1801 subtree. New assignments can only be made by a standards action as 1802 specified in [RFC2434]. 1804 11.1. IANA Considerations for MPLS-FTN-STD-MIB 1806 The IANA is requested to assign mplsStdMIB.8 to the MPLS-FTN-STD-MIB 1807 module specified in this document. 1809 12. References 1811 12.1. Normative References 1813 [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate 1814 Requirement Levels", RFC 2119, BCP 14, March 1997. 1816 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 1817 J., Rose, M., and S. Waldbusser, "Structure of 1818 Management Information Version 2 (SMIv2)", STD 58, RFC 1819 2578, April 1999. 1821 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 1822 J., Rose, M., and S. Waldbusser, "Textual Conventions 1823 for SMIv2", STD 58, RFC 2579, April 1999. 1825 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 1826 J., Rose, M., and S. Waldbusser, "Conformance 1827 Statements for SMIv2", STD 58, RFC 2580, April 1999. 1829 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces 1830 Group MIB", RFC 2863, June 2000. 1832 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, 1833 "Multiprotocol Label Switching Architecture", RFC 1834 3031, January 2001. 1836 [RFC3289] Baker, F., Chan, K., and A. Smith, "Management 1837 Information Base for the Differentiated Services 1838 Architecture", RFC 3289, May 2002. 1840 [RFC3291] Daniele, M., Haberman, B., Routhier, S. and J. 1841 Schoenwaelder, "Textual Conventions for Internet 1842 Network Addresses", RFC 3291, May 2002. 1844 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1845 Architecture for Describing Simple Network Management 1846 Protocol (SNMP) Management Frameworks", RFC 3411, 1847 December 2002. 1849 [LSRMIB] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS 1850 Label Switch Router Management Information Base ", 1851 Internet Draft , 1852 August 2003. 1854 [TEMIB] Srinivasan, C., Viswanathan, A. and Nadeau, T., "MPLS 1855 Traffic Engineering Management Information Base ", 1856 Internet Draft , August 1857 2003. 1859 [TCMIB] Nadeau, T., Cucchiara, J., Srinivasan, C., 1860 Viswanathan, A., Sjostrand, H. and K. Kompella, 1861 "Definition of Textual Conventions and OBJECT- 1862 IDENTITIES for Multi-Protocol Label Switching (MPLS) 1863 Management", Internet Draft , August 2003. 1866 [MPLSMGMT] Nadeau, T., Srinivasan, C., and A. Farrel, 1867 "Multiprotocol Label Switching (MPLS) Management 1868 Overview", Internet Draft , September 2003. 1871 12.2. Informative References 1873 [RFC791] J. Postel, "Internet Protocol", RFC 791, STD 5, 1874 September 1981. 1876 [RFC1519] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless 1877 Inter-Domain Routing (CIDR): an Address Assignment and 1878 Aggregation Strategy", RFC 1519, September 1993. 1880 [RFC2026] S. Bradner, "The Internet Standards Process -- 1881 Revision 3", RFC 2026, October 1996. 1883 [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing 1884 an IANA Considerations Section in RFCs", BCP 26, RFC 1885 2434, October 1998. 1887 [RFC2460] Deering, S., and R. Hinden, "Internet Protocol, 1888 Version 6 (IPv6) Specification", RFC 2460, December 1889 1998. 1891 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 1892 "Definition of the Differentiated Services Field (DS 1893 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1894 December 1998. 1896 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 1897 "Introduction and Applicability Statements for 1898 Internet-Standard Management Framework", RFC 3410, 1899 December 2002. 1901 13. Authors' Addresses 1903 Thomas D. Nadeau 1904 Cisco Systems, Inc. 1905 300 Apollo Drive 1906 Chelmsford, MA 01824 1907 Phone: +1-978-244-3051 1908 Email: tnadeau@cisco.com 1910 Cheenu Srinivasan 1911 Bloomberg L.P. 1912 499 Park Avenue 1913 New York, NY 10022 1914 Tel: +1-212-893-3682 1915 Email: cheenu@bloomberg.net 1917 Arun Viswanathan 1918 Force10 Networks, Inc. 1919 1440 McCarthy Blvd 1920 Milpitas, CA 95035 1921 Phone: +1-408-571-3516 1922 Email: arunv@force10networks.com 1924 14. Acknowledgements 1926 We would particularly like to thank Bert Wijnen for the substantial 1927 time and effort he spent in helping us improve this document. We 1928 would also like to thank David Perkins, Joan Cucchiara, Mike Piecuch, 1929 and Adrien Grise for their insightful comments and additions to this 1930 document. 1932 15. Full Copyright Statement 1934 Copyright (C) The Internet Society (2001). All Rights Reserved. 1936 This document and translations of it may be copied and furnished to 1937 others, and derivative works that comment on or otherwise explain it 1938 or assist in its implementation may be prepared, copied, published 1939 and distributed, in whole or in part, without restriction of any 1940 kind, provided that the above copyright notice and this paragraph are 1941 included on all such copies and derivative works. However, this 1942 document itself may not be modified in any way, such as by removing 1943 the copyright notice or references to the Internet Society or other 1944 Internet organizations, except as needed for the purpose of 1945 developing Internet standards in which case the procedures for 1946 copyrights defined in the Internet Standards process must be 1947 followed, or as required to translate it into languages other than 1948 English. 1950 The limited permissions granted above are perpetual and will not be 1951 revoked by the Internet Society or its successors or assigns. This 1952 document and the information contained herein is provided on an "AS 1953 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1954 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1955 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1956 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1957 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1959 16. Intellectual Property Considerations 1961 The IETF takes no position regarding the validity or scope of any 1962 intellectual property or other rights that might be claimed to 1963 pertain to the implementation or use of the technology described in 1964 this document or the extent to which any license under such rights 1965 might or might not be available; neither does it represent that it 1966 has made any effort to identify any such rights. Information on the 1967 IETF's procedures with respect to rights in standards-track and 1968 standards related documentation can be found in BCP-11. Copies of 1969 claims of rights made available for publication and any assurances of 1970 licenses to be made available, or the result of an attempt made to 1971 obtain a general license or permission for the use of such 1972 proprietary rights by implementers or users of this specification can 1973 be obtained from the IETF Secretariat. 1975 The IETF invites any interested party to bring to its attention any 1976 copyrights, patents or patent applications, or other proprietary 1977 rights which may cover technology that may be required to practice 1978 this standard. Please address the information to the IETF Executive 1979 Director.