idnits 2.17.1 draft-ietf-mpls-tc-mib-05.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 document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 762 has weird spacing: '...for the purpo...' -- 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 (November 2002) is 7825 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '21' on line 70 == Missing Reference: 'CCAMP-ARCH' is mentioned on line 442, but not defined -- Looks like a reference, but probably isn't: '5' on line 385 ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) Summary: 16 errors (**), 0 flaws (~~), 4 warnings (==), 4 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: May 2003 Joan Cucchiara 4 Consultant 5 Cheenu Srinivasan 6 Parama Networks, Inc. 7 Arun Viswanathan 8 Force10 Networks, Inc. 9 Hans Sjostrand 10 ipUnplugged 12 November 2002 14 Definitions of Textual Conventions for Multiprotocol Label 15 Switching (MPLS) Management 17 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC 2026. Internet-Drafts are 23 working documents of the Internet Engineering Task Force (IETF), its 24 areas, and its working groups. Note that other groups may also 25 distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress". 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Distribution of this document is unlimited. Please send comments to 39 the Multiprotocol Label Switching (mpls) Working Group, mpls@uu.net. 41 Copyright Notice 43 Copyright (C) The Internet Society (2002). All Rights Reserved. 45 Abstract 47 This memo describes Textual Conventions for use in definitions of 48 management information for Multiprotocol Label Switching (MPLS) 49 networks. 51 Table of Contents 53 1 Introduction ................................................. 3 54 2 The SNMP Management Framework ................................ 3 55 3 MPLS Textual Conventions MIB Definitions ..................... 4 56 4 References ................................................... 15 57 5 Security Considerations ...................................... 16 58 6 Authors' Addresses ........................................... 17 59 7 Full Copyright Statement ..................................... 17 61 1. Introduction 63 This document defines a MIB which contains Textual Conventions for 64 use in definitions of management information for Multi-Protocol Label 65 Switching (MPLS) networks. 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [21]. 71 For an introduction to the concepts of MPLS, see [RFC3031]. 73 2. The SNMP Management Framework 75 The SNMP Management Framework presently consists of five major 76 components: 78 o An overall architecture, described in RFC 2571 [RFC2571]. 80 o Mechanisms for describing and naming objects and events for the 81 purpose of management. The first version of this Structure of 82 Management Information (SMI) is called SMIv1 and described in 83 STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 84 1215 [RFC1215]. The second version, called SMIv2, is described 85 in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and 86 STD 58, RFC 2580 [RFC2580]. 88 o Message protocols for transferring management information. The 89 first version of the SNMP message protocol is called SNMPv1 and 90 described in STD 15, RFC 1157 [RFC1157]. A second version of 91 the SNMP message protocol, which is not an Internet standards 92 track protocol, is called SNMPv2c and described in RFC 1901 93 [RFC1901] and RFC 1906 [RFC1906]. The third version of the 94 message protocol is called SNMPv3 and described in RFC 1906 95 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 97 o Protocol operations for accessing management information. The 98 first set of protocol operations and associated PDU formats is 99 described in STD 15, RFC 1157 [RFC1157]. A second set of 100 protocol operations and associated PDU formats is described in 101 RFC 1905 [RFC1905]. 103 o A set of fundamental applications described in RFC 2573 104 [RFC2573] and the view-based access control mechanism described 105 in RFC 2575 [RFC2575]. 107 A more detailed introduction to the current SNMP Management Framework 108 can be found in RFC 2570 [RFC2570]. 110 Managed objects are accessed via a virtual information store, termed 111 the Management Information Base or MIB. Objects in the MIB are 112 defined using the mechanisms defined in the SMI. 114 This memo specifies a MIB module that is compliant to the SMIv2. A 115 MIB conforming to the SMIv1 can be produced through the appropriate 116 translations. The resulting translated MIB must be semantically 117 equivalent, except where objects or events are omitted because no 118 translation is possible. Some machine readable information in SMIv2 119 will be converted into textual descriptions in SMIv1 during the 120 translation process. However, this loss of machine readable 121 information is not considered to change the semantics of the MIB. 123 3. MPLS Textual Conventions MIB Definitions 125 MPLS-TC-MIB DEFINITIONS ::= BEGIN 127 IMPORTS 129 MODULE-IDENTITY, Unsigned32, Integer32, transmission 130 FROM SNMPv2-SMI 132 TEXTUAL-CONVENTION 133 FROM SNMPv2-TC; 135 mplsTCMIB MODULE-IDENTITY 136 LAST-UPDATED "200211031200Z" -- 3 Nov 2002 12:00:00 GMT 137 ORGANIZATION 138 "IETF Multiprotocol Label Switching (MPLS) Working 139 Group." 140 CONTACT-INFO 141 " Thomas D. Nadeau 142 Cisco Systems, Inc. 143 tnadeau@cisco.com 145 Joan Cucchiara 146 Consultant 147 jcucchiara@mindspring.com 149 Cheenu Srinivasan 150 Parama Networks, Inc. 151 cheenu@paramanet.com 153 Arun Viswanathan 154 Force10 Networks, Inc. 155 arun@force10networks.com 157 Hans Sjostrand 158 ipUnplugged 159 hans@ipunplugged.com 161 Email comments to the MPLS WG Mailing List at 162 mpls@uu.net." 163 DESCRIPTION 164 "This MIB module defines Textual Conventions 165 for use in definitions of management 166 information for Multi-Protocol Label Switching 167 (MPLS) networks." 169 REVISION "200211031200Z" -- 3 Nov 2002 12:00:00 GMT 170 DESCRIPTION 171 "Initial version published as part of RFC XXXX." 172 ::= { mplsMIB 1 } 174 -- This object identifier needs to be assigned by IANA. 175 -- Since mpls has been assigned an ifType of 166 we recommend 176 -- that this OID be 166 as well. 178 mplsMIB OBJECT IDENTIFIER 179 ::= { transmission XXX } 181 -- Textual Conventions are in alphabetical order. 183 MplsAtmVcIdentifier ::= TEXTUAL-CONVENTION 184 DISPLAY-HINT "d" 185 STATUS current 186 DESCRIPTION 187 "A Label Switching Router (LSR) that 188 creates LDP sessions on ATM interfaces 189 uses the VCI or VPI/VCI field to hold the 190 LDP Label. 192 VCI values MUST NOT be in the 0-31 range. 193 The values 0 to 31 are reserved for other uses 194 by the ITU and ATM Forum. The value 195 of 32 can only be used for the Control VC, 196 although values greater than 32 could be 197 configured for the Control VC. 199 If a value from 0 to 31 is used for a VCI 200 the management entity controlling the LDP 201 subsystem should reject this with an 202 inconsistentValue error. Also, if 203 the value of 32 is used for a VC which is 204 NOT the Control VC, this should 205 result in an inconsistentValue error." 206 REFERENCE 207 "[RFC3035] Davie, B., Lawerence J., McCloghrie, K., 208 Rosen, E., Swallow G., Rekhter, Y., and 209 P. Doolan, 'MPLS using LDP and ATM VC Switching', 210 RFC 3035, January 2001." 211 SYNTAX Integer32 (32..65535) 213 MplsBitRate ::= TEXTUAL-CONVENTION 214 DISPLAY-HINT "d" 215 STATUS current 216 DESCRIPTION 217 "An estimate of bandwidth in units of 1,000 bits per 218 second. If this object reports a value of 'n' then 219 the rate of the object is somewhere in the range of 220 'n-500' to 'n+499'. For objects which do not vary 221 in bit rate, or for those where no accurate 222 estimation can be made, this object should contain 223 the nominal bit rate. A value of 0 indicates best 224 effort treatment." 225 SYNTAX Integer32 (0|500..2147483647) 227 MplsBurstSize ::= TEXTUAL-CONVENTION 228 DISPLAY-HINT "d" 229 STATUS current 230 DESCRIPTION 231 "The number of octets of MPLS data that the stream 232 may send back-to-back without concern for policing. 233 The value of zero indicates that an implementation 234 does not support Burst Size." 235 SYNTAX Unsigned32 (0..4294967295) 237 MplsExtendedTunnelId ::= TEXTUAL-CONVENTION 238 STATUS current 239 DESCRIPTION 240 "A unique identifier for an MPLS Tunnel. This may 241 represent an IPv4 address of the ingress or egress 242 LSR for the tunnel. This value is derived from the 243 Extended Tunnel Id in RSVP or the Ingress Router ID 244 for CR-LDP." 245 REFERENCE 246 "[RFC3209] Awduche, D., et al., 'RSVP-TE: Extensions 247 to RSVP for LSP Tunnels', RFC 3209, December 2001. 249 [RFC3212] Jamoussi, B., et al., 'Constraint-Based 250 LSP Setup using LDP', RFC 3212, January 2002." 251 SYNTAX Unsigned32 253 MplsOwner ::= TEXTUAL-CONVENTION 254 STATUS current 255 DESCRIPTION 256 "The entity that originally created the object in 257 question. The values of this enumeration are 258 defined as follows: 260 other(1) - This is used when an entity which has not 261 been enumerated in this textual convention but 262 which is known by the agent. 264 snmp(2) - The Simple Network Management Protocol was 265 used to configure this object initially. 267 ldp(3 - The Label Distribution Protocol was used to 268 configure this object initially. 270 rsvp(4) - The Resource Reservation Protocol was used 271 to configure this object initially. 273 crldp(5) - The Constraint-Based Label Distribution 274 Protocol was used to configure this object 275 initially. 277 policyAgent(6) - A policy agent (perhaps in 278 combination with one of the above protocols) was 279 used to configure this object initially. 281 unknown(7) - the agent cannot discern which 282 component created the object. 284 An object created by the ldp(3), rsvp(4), crldp(5) 285 or policyAgent(6) MAY be modified through operator 286 intervention using other(1) or snmp(2). In 287 particular, operators may bring rows in and 288 out of service or modify their values. 289 In all other respects, the MplsOwner is 290 the only source allowed to modify the status of 291 the object. 293 Agents receiving requests which violate these 294 guidelines MUST return an inconsistentValue(12) 295 error." 296 SYNTAX INTEGER { 297 other(1), 298 snmp(2), 299 ldp(3), 300 rsvp(4), 301 crldp(5), 302 policyAgent(6), 303 unknown (7) 304 } 306 MplsLSPID ::= TEXTUAL-CONVENTION 307 STATUS current 308 DESCRIPTION 309 "A unique identifier within an MPLS network that is 310 assigned to each LSP. This is assigned at the head 311 end of the LSP and can be used by all LSRs 312 to identify this LSP. This value is piggybacked by 313 the signaling protocol when this LSP is signaled 314 within the network. This identifier can then be 315 used at each LSR to identify which labels are being 316 swapped to other labels for this LSP. This object 317 can also be used to disambiguate LSPs that 318 share the same RSVP sessions between the same 319 source and destination. 321 For LSPs established using CR-LDP, the LSPID is 322 composed of the ingress LSR Router ID (or any of 323 its own IPv4 addresses) and a locally unique 324 CR-LSP ID to that LSR. The first two bytes carry 325 the CR-LSPID, and the remaining 4 bytes carry 326 the Router ID. The LSPID is useful in network 327 management, in CR-LSP repair, and in using 328 an already established CR-LSP as a hop in an ER-TLV. 330 For LSPs signaled using RSVP-TE, the LSP ID is 331 defined as a 16-bit (2 byte) identifier used 332 in the SENDER_TEMPLATE and the FILTER_SPEC 333 that can be changed to allow a sender to 334 share resources with itself. The length of this 335 object should only be 2 or 6 bytes. If the length 336 of this octet string is 2 bytes, then it must 337 identify an RSVP-TE LSPID, or it is 6 bytes, 338 it must contain a CR-LDP LSPID." 339 REFERENCE 340 "See [RFC3209] for RSVP-TE LSPID and [RFC3212] for 341 LSPID in CR-LDP." 342 SYNTAX OCTET STRING (SIZE (2|6)) 344 MplsLabel ::= TEXTUAL-CONVENTION 345 STATUS current 346 DESCRIPTION 347 "This value represents an MPLS label as defined in 348 [RFC3031], [RFC3032], [RFC3034], [RFC3035] and 349 [CCAMP-ARCH]. 351 The label contents are specific to the label being 352 represented, such as: 354 * The label carried in an MPLS shim header 355 (for LDP this is the Generic Label) is a 20-bit 356 number represented by 4 octets. Bits 0-19 contain 357 a label or a reserved label value. Bits 20-31 358 MUST be zero. 360 The following is quoted directly from [RFC3032]. 361 There are several reserved label values: 363 i. A value of 0 represents the 364 'IPv4 Explicit NULL Label'. This label 365 value is only legal at the bottom of the 366 label stack. It indicates that the label 367 stack must be popped, and the forwarding 368 of the packet must then be based on the 369 IPv4 header. 371 ii. A value of 1 represents the 372 'Router Alert Label'. This label value is 373 legal anywhere in the label stack except at 374 the bottom. When a received packet 375 contains this label value at the top of 376 the label stack, it is delivered to a 377 local software module for processing. 378 The actual forwarding of the packet 379 is determined by the label beneath it 380 in the stack. However, if the packet is 381 forwarded further, the Router Alert Label 382 should be pushed back onto the label stack 383 before forwarding. The use of this label 384 is analogous to the use of the 385 'Router Alert Option' in IP packets [5] 386 [Reference to RFC2113]. Since this label 387 cannot occur at the bottom of the stack, 388 it is not associated with a 389 particular network layer protocol. 391 iii. A value of 2 represents the 392 'IPv6 Explicit NULL Label'. This label 393 value is only legal at the bottom of the 394 label stack. It indicates that the label 395 stack must be popped, and the forwarding 396 of the packet must then be based on the 397 IPv6 header. 399 iv. A value of 3 represents the 400 'Implicit NULL Label'. 401 This is a label that an LSR may assign and 402 distribute, but which never actually 403 appears in the encapsulation. When an 404 LSR would otherwise replace the label 405 at the top of the stack with a new label, 406 but the new label is 'Implicit NULL', 407 the LSR will pop the stack instead of 408 doing the replacement. Although 409 this value may never appear in the 410 encapsulation, it needs to be specified in 411 the Label Distribution Protocol, so a value 412 is reserved. 414 v. Values 4-15 are reserved. 416 * The frame relay label can be either 10-bits or 417 23-bits depending on the DLCI field size and the 418 upper 22-bits or upper 9-bits must be zero, 419 respectively. 421 * For an ATM label the lower 16-bits represents the 422 VCI, the next 12-bits represents the VPI and the 423 remaining bits MUST be zero. 425 * The Generalized-MPLS (GMPLS) label contains a 426 value greater than 2^24-1 and used in GMPLS 427 as defined in [CCAMP-ARCH]." 429 REFERENCE 430 "[RFC3031] Multiprotocol Label Switching 431 Architecture, Rosen et al., RFC 3031, August 1999. 433 [RFC3032] MPLS Label Stack Encoding, Rosen et al., 434 RFC 3032, January 2001. 436 [RFC3034] Use of Label Switching on Frame Relay 437 Networks, Conta et al., RFC 3034, January 2001. 439 [RFC3035] MPLS using LDP and ATM VC Switching, 440 Davie et al., RFC 3035, January 2001. 442 [CCAMP-ARCH] Generalized Multi-Protocol Label 443 Switching (GMPLS) Architecture, Mannie (Editor), 444 draft-ietf-ccamp-gmpls-architecture-02.txt, 445 March 2002." 446 SYNTAX Unsigned32 (0..4294967295) 448 MplsLabelDistributionMethod ::= TEXTUAL-CONVENTION 449 STATUS current 450 DESCRIPTION 451 "The label distribution method which is also called 452 the label advertisement mode (see LDP Specification). 453 Each interface on an LSR is configured to operate 454 in either Downstream Unsolicited or Downstream 455 on Demand." 456 REFERENCE 457 "[RFC3031] Multiprotocol Label Switching 458 Architecture, Rosen et al., RFC 3031, August 1999. 460 [RFC3036] LDP Specification, Andersson, L., et. al., 461 RFC 3036, Section 2.6.3., January 2001." 462 SYNTAX INTEGER { 463 downstreamOnDemand(1), 464 downstreamUnsolicited(2) 465 } 467 MplsLspType ::= TEXTUAL-CONVENTION 468 STATUS current 469 DESCRIPTION 470 "Types types of Label Switch Paths (LSPs) 471 on an Label Switching Router (LSR) are: 473 unknown(1) -- if the LSP is not known 474 to be one of the following. 476 terminatingLsp(2) -- if the LSP terminates 477 on the LSR, then this 478 is an ingressing LSP 479 which ends on the LSR, 481 originatingLsp(3) -- if the LSP originates 482 from the LSR, then this 483 is an egressing LSP which is 484 the head-end of the LSP, 486 crossConnectingLsp(4) -- if the LSP ingresses 487 and egresses on the LSR, 488 then it is cross-connecting 489 on that LSR." 490 SYNTAX INTEGER { 491 unknown(1), 492 terminatingLsp(2), 493 originatingLsp(3), 494 crossConnectingLsp(4) 495 } 497 MplsLsrIndex ::= TEXTUAL-CONVENTION 498 STATUS current 499 DESCRIPTION 500 "Represents a generic index used throughout the 501 MPLS-LSR-MIB as a general index in the 502 mplsInSegmentTable, mplsOutSegmentTable 503 and mplsXCTable." 504 SYNTAX OCTET STRING (SIZE(1..34)) 506 MplsRetentionMode ::= TEXTUAL-CONVENTION 507 STATUS current 508 DESCRIPTION 509 "The label retention mode which specifies whether 510 an LSR maintains a label binding for a FEC learned 511 from a neighbor that is not its next hop for the 512 FEC. 514 If the value is conservative(1) then advertised 515 label mappings are retained only if they will be 516 used to forward packets, i.e. if label came from 517 a valid next hop. 519 If the value is liberal(2) then all advertised label 520 mappings are retained whether they are from a 521 valid next hop or not." 522 REFERENCE 523 "[RFC3031] Multiprotocol Label Switching 524 Architecture, Rosen et al., RFC 3031, August 1999. 526 [RFC3036] LDP Specification, Andersson, L., et. al., 527 RFC 3036, Section 2.6.2., January 2001." 528 SYNTAX INTEGER { 529 conservative(1), 530 liberal(2) 531 } 533 MplsLdpIdentifier ::= TEXTUAL-CONVENTION 534 STATUS current 535 DESCRIPTION 536 "The LDP identifier is a six octet quantity which is 537 used to identify an Label Switching Router (LSR) 538 label space. 540 The first four octets identify the LSR and must be 541 a globally unique value, such as a 32-bit router ID 542 assigned to the LSR, and the last two octets 543 identify a specific label space within the LSR." 544 SYNTAX OCTET STRING (SIZE (6)) 546 MplsLdpLabelType ::= TEXTUAL-CONVENTION 547 STATUS current 548 DESCRIPTION 549 "The Layer 2 label types which are defined for MPLS 550 LDP and/or CR-LDP are generic(1), atm(2), or 551 frameRelay(3)." 552 SYNTAX INTEGER { 553 generic(1), 554 atm(2), 555 frameRelay(3) 556 } 558 MplsLsrIdentifier ::= TEXTUAL-CONVENTION 559 STATUS current 560 DESCRIPTION 561 "The Label Switching Router (LSR) identifier is the 562 first 4 bytes of the Label Distribution Protocol 563 (LDP) identifier." 564 SYNTAX OCTET STRING (SIZE (4)) 566 MplsPathIndex ::= TEXTUAL-CONVENTION 567 STATUS current 568 DESCRIPTION 569 "A unique value to index (by Path number) an entry 570 in a table." 571 SYNTAX Unsigned32(1..4294967295) 573 MplsPathIndexOrZero ::= TEXTUAL-CONVENTION 574 STATUS current 575 DESCRIPTION 576 "A unique identifier used to identify a specific path 577 used by a tunnel. A value of 0 (zero) means that 578 no path is in use." 579 SYNTAX Unsigned32 581 MplsTunnelAffinity ::= TEXTUAL-CONVENTION 582 STATUS current 583 DESCRIPTION 584 "Describes the configured 32-bit Include-any, 585 include-all, or exclude-all constraint for 586 constraint-based link selection." 587 REFERENCE 588 "See section 4.7.4 in [RFC3209]." 589 SYNTAX Unsigned32 591 MplsTunnelIndex ::= TEXTUAL-CONVENTION 592 STATUS current 593 DESCRIPTION 594 "A unique index into mplsTunnelTable. 595 For tunnels signaled using RSVP, this value 596 should correspond to the RSVP destination 597 port used for the RSVP-TE session." 598 SYNTAX Integer32 (1..65535) 600 MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION 601 STATUS current 602 DESCRIPTION 603 "Instance index into mplsTunnelTable. The 604 tunnel entry with instance index 0 should 605 refer to the configured tunnel interface 606 (if one exists), and values greater an 0 607 should be used to indicate signaled (or backup) 608 tunnel LSP instances. For tunnel LSPs signaled using 609 RSVP, this value should correspond to the 610 RSVP source port used for the RSVP-TE session." 611 SYNTAX Unsigned32 (0..65535) 613 END 615 4. References 617 [RFC3212] Jamoussi, B., (editor), et. al. "Constraint-Based LSP Setup 618 using LDP", RFC 3212, January 2002. 620 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 621 Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", 622 RFC 3209, December 2001. 624 [RFC3031] Rosen, E., Viswananthan, A., and R. Callon, "Multiprotocol 625 Label Switching Architecture", RFC 3031, January 2001. 627 [RFC3032] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., 628 Federokow, G., Li, T., and A. Conta, "MPLS Label Stack 629 Encoding", RFC 3032, January 2001. 631 [RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching 632 on Frame Relay Networks Specification", RFC 3034, January 633 2001. 635 [RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, 636 G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC 637 Switching", RFC 3035, January 2001. 639 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. 640 Thomas, "LDP Specification", RFC 3036, January 2001. 642 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 643 for Describing SNMP Management Frameworks", RFC 2571, April 644 1999. 646 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification 647 of Management Information for TCP/IP-based Internets", STD 648 16, RFC 1155, May 1990. 650 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 651 16, RFC 1212, March 1991. 653 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the 654 SNMP", RFC 1215, March 1991. 656 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 657 Rose, M., and S. Waldbusser, "Structure of Management 658 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 659 1999. 661 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 662 Rose, M., and S. Waldbusser, "Textual Conventions for 663 SMIv2", STD 58, RFC 2579, April 1999. 665 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 666 Rose, M., and S. Waldbusser, "Conformance Statements for 667 SMIv2", STD 58, RFC 2580, April 1999. 669 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 670 Network Management Protocol", STD 15, RFC 1157, May 1990. 672 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 673 "Introduction to Community-based SNMPv2", RFC 1901, January 674 1996. 676 [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 677 "Transport Mappings for Version 2 of the Simple Network 678 Management Protocol (SNMPv2)", RFC 1906, January 1996. 680 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 681 Processing and Dispatching for the Simple Network Management 682 Protocol (SNMP)", RFC 2572, April 1999. 684 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 685 (USM) for version 3 of the Simple Network Management 686 Protocol (SNMPv3)", RFC 2574, April 1999. 688 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 689 "Protocol Operations for Version 2 of the Simple Network 690 Management Protocol (SNMPv2)", RFC 1905, January 1996. 692 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", 693 RFC 2573, April 1999. 695 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 696 Access Control Model (VACM) for the Simple Network 697 Management Protocol (SNMP)", RFC 2575, April 1999. 699 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 700 "Introduction to Version 3 of the Internet-standard Network 701 Management Framework", RFC 2570, April 1999. 703 5. Security Considerations 705 This module does not define any management objects. Instead, it 706 defines a set of textual conventions which may be used by other MPLS 707 MIB modules to define management objects. 709 Meaningful security considerations can only be written in the MIB 710 modules that define management objects. Therefore, this document has 711 no impact on the security of the Internet. 713 6. Authors' Addresses 715 Thomas D. Nadeau 716 Cisco Systems, Inc. 717 250 Apollo Drive 718 Chelmsford, MA 01824 719 Phone: +1-978-244-3051 720 Email: tnadeau@cisco.com 722 Joan Cucchiara 723 Consultant 724 PO Box 1010 725 Concord, MA 726 Phone: +1-508-303-8200 x302 727 Email: jcucchiara@mindspring.com 729 Cheenu Srinivasan 730 Parama Networks, Inc. 731 1030 Broad Street 732 Shrewsbury, NJ 07702 733 Phone: +1-732-544-9120 x731 734 Email: cheenu@paramanet.com 736 Arun Viswanathan 737 Force10 Networks, Inc. 738 1440 McCarthy Blvd 739 Milpitas, CA 95035 740 Phone: +1-408-571-3516 741 Email: arun@force10networks.com 743 Hans Sjostrand 744 ipUnplugged 745 P.O. Box 101 60 746 S-121 28 Stockholm, Sweden 747 Phone: +46-8-725-5930 748 Email: hans@ipunplugged.com 750 7. Full Copyright Statement 752 Copyright (C) The Internet Society (2002). All Rights Reserved. 754 This document and translations of it may be copied and furnished to 755 others, and derivative works that comment on or otherwise explain it 756 or assist in its implementation may be prepared, copied, published 757 and distributed, in whole or in part, without restriction of any 758 kind, provided that the above copyright notice and this paragraph are 759 included on all such copies and derivative works. However, this 760 document itself may not be modified in any way, such as by removing 761 the copyright notice or references to the Internet Society or other 762 Internet organizations, except as needed for the purpose of 763 developing Internet standards in which case the procedures for 764 copyrights defined in the Internet Standards process must be 765 followed, or as required to translate it into languages other than 766 English. 768 The limited permissions granted above are perpetual and will not be 769 revoked by the Internet Society or its successors or assigns. 771 This document and the information contained herein is provided on an 772 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 773 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 774 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 775 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 776 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.