idnits 2.17.1 draft-ietf-mpls-tc-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: ---------------------------------------------------------------------------- ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 408 has weird spacing: '... object can a...' == Line 719 has weird spacing: '... octets cont...' == Line 720 has weird spacing: '...terface netw...' == Line 909 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 (August 2003) is 7531 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) == Missing Reference: 'RFC2119' is mentioned on line 74, but not defined == Unused Reference: 'RFC3032' is defined on line 750, but no explicit reference was found in the text == Unused Reference: 'RFC3034' is defined on line 754, but no explicit reference was found in the text == Unused Reference: 'RFC3035' is defined on line 758, but no explicit reference was found in the text == Unused Reference: 'RFC3036' is defined on line 762, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 765, but no explicit reference was found in the text == Unused Reference: 'RFC3212' is defined on line 769, but no explicit reference was found in the text == Unused Reference: 'RFC3291' is defined on line 772, but no explicit reference was found in the text == Unused Reference: 'GMPLS-ARCH' is defined on line 776, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) ** Obsolete normative reference: RFC 3291 (Obsoleted by RFC 4001) Summary: 5 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Nadeau 2 Internet-Draft Cisco Systems, Inc. 3 Expires: February 2004 J. Cucchiara 4 Artel 5 (Editors) 7 August 2003 9 Definitions of Textual Conventions for Multiprotocol Label 10 Switching (MPLS) Management 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Distribution of this document is unlimited. Please send comments to 34 the Multiprotocol Label Switching (mpls) Working Group, mpls@uu.net. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This memo defines a Management Information Base (MIB) module which 43 contains Textual Conventions to represent commonly used Mulitprotocol 44 Label Switching (MPLS) management information. The intent is that 45 these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS 46 related MIB modules that would otherwise define their own 47 representations. 49 Table of Contents 51 1 Introduction ................................................. 4 52 2 The Internet-Standard Management Framework ................... 4 53 3 MPLS Textual Conventions MIB Definitions ..................... 4 54 4 Normative References ......................................... 19 55 5 Informative References ....................................... 20 56 6 Security Considerations ...................................... 20 57 7 IANA Considerations .......................................... 20 58 8 Contributors ................................................. 21 59 9 Acknowledgements ............................................. 21 60 10 Intellectual Property Notice ................................ 22 61 11 Authors' Addresses .......................................... 22 62 12 Full Copyright Statement .................................... 23 64 1. Introduction 66 This document defines a MIB module which contains Textual Conventions 67 for Multi-Protocol Label Switching (MPLS) networks. These Textual 68 Conventions should be imported by MIB modules which manage MPLS 69 networks. 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119 [RFC2119]. 75 For an introduction to the concepts of MPLS, see [RFC3031]. 77 2. The Internet-Standard Management Framework 79 For a detailed overview of the documents that describe the current 80 Internet-Standard Management Framework, please refer to section 7 of 81 RFC 3410 [RFC3410]. 83 Managed objects are accessed via a virtual information store, termed 84 the Management Information Base or MIB. MIB objects are generally 85 accessed through the Simple Network Management Protocol (SNMP). 86 Objects in the MIB are defined using the mechanisms defined in the 87 Structure of Management Information (SMI). This memo specifies a MIB 88 module that is compliant to the SMIv2, which is described in STD 58, 89 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 90 [RFC2580]. 92 3. MPLS Textual Conventions MIB Definitions 94 MPLS-TC-STD-MIB DEFINITIONS ::= BEGIN 96 IMPORTS 98 MODULE-IDENTITY, Unsigned32, Integer32, transmission 99 FROM SNMPv2-SMI 101 TEXTUAL-CONVENTION 102 FROM SNMPv2-TC; 104 mplsTCStdMIB MODULE-IDENTITY 105 LAST-UPDATED "200308061200Z" -- 6 August 2003 12:00:00 GMT 106 ORGANIZATION 107 "IETF Multiprotocol Label Switching (MPLS) Working 108 Group." 109 CONTACT-INFO 110 " Thomas D. Nadeau 111 Cisco Systems, Inc. 112 tnadeau@cisco.com 114 Joan Cucchiara 115 Artel 116 jcucchiara@artel.com 118 Cheenu Srinivasan 119 Bloomberg L.P. 120 cheenu@bloomberg.net 122 Arun Viswanathan 123 Force10 Networks, Inc. 124 arunv@force10networks.com 126 Hans Sjostrand 127 ipUnplugged 128 hans@ipunplugged.com 130 Kireeti Kompella 131 Juniper Networks 132 kireeti@juniper.net 134 Email comments to the MPLS WG Mailing List at 135 mpls@uu.net." 136 DESCRIPTION 137 "Copyright (C) The Internet Society (2003). This 138 version of this MIB module is part of RFCXXX; see 139 the RFC itself for full legal notices. 141 This MIB module defines Textual Conventions 142 for concepts used in Multi-Protocol Label 143 Switching (MPLS) networks." 145 REVISION "200308061200Z" -- 6 August 2003 12:00:00 GMT 146 DESCRIPTION 147 "Initial version published as part of RFC XXXX." 149 -- Please see the IANA Considerations Section. 150 -- The requested mplsStdMIB subId is 1, e.g. 151 -- ::= { mplsStdMIB 1 } 153 ::= { mplsStdMIB XXX } -- to be assigned by IANA 155 mplsStdMIB OBJECT IDENTIFIER 157 -- This object identifier needs to be assigned by IANA. 158 -- Since mpls has been assigned an ifType of 166 we recommend 159 -- that this OID be 166 as well, e.g. 160 -- ::= { transmission 166 } 162 ::= { transmission XXX } -- to be assigned by IANA 164 MplsAtmVcIdentifier ::= TEXTUAL-CONVENTION 165 DISPLAY-HINT "d" 166 STATUS current 167 DESCRIPTION 168 "A Label Switching Router (LSR) that 169 creates LDP sessions on ATM interfaces 170 uses the VCI or VPI/VCI field to hold the 171 LDP Label. 173 VCI values MUST NOT be in the 0-31 range. 174 The values 0 to 31 are reserved for other uses 175 by the ITU and ATM Forum. The value 176 of 32 can only be used for the Control VC, 177 although values greater than 32 could be 178 configured for the Control VC. 180 If a value from 0 to 31 is used for a VCI 181 the management entity controlling the LDP 182 subsystem should reject this with an 183 inconsistentValue error. Also, if 184 the value of 32 is used for a VC which is 185 NOT the Control VC, this should 186 result in an inconsistentValue error." 187 REFERENCE 188 "MPLS using LDP and ATM VC Switching, RFC3035." 189 SYNTAX Integer32 (32..65535) 191 MplsBitRate ::= TEXTUAL-CONVENTION 192 DISPLAY-HINT "d" 193 STATUS current 194 DESCRIPTION 195 "If the value of this object is greater than zero, 196 then this represents the bandwidth of this MPLS 197 interface (or Label Switched Path) in units of 198 '1,000 bits per second'. 200 The value, when greater than zero, represents the 201 bandwidth of this MPLS interface (rounded to the 202 nearest 1,000) in units of 1,000 bits per second. 203 If the bandwidth of the MPLS interface is between 204 ((n * 1000) - 500) and ((n * 1000) + 499), the value 205 of this object is n, such that n > 0. 207 If the value of this object is 0 (zero), this 208 means that the traffic over this MPLS interface is 209 considered to be best effort." 210 SYNTAX Unsigned32 (0|1..4294967295) 212 MplsBurstSize ::= TEXTUAL-CONVENTION 213 DISPLAY-HINT "d" 214 STATUS current 215 DESCRIPTION 216 "The number of octets of MPLS data that the stream 217 may send back-to-back without concern for policing. 218 The value of zero indicates that an implementation 219 does not support Burst Size." 220 SYNTAX Unsigned32 (0..4294967295) 222 MplsExtendedTunnelId ::= TEXTUAL-CONVENTION 223 STATUS current 224 DESCRIPTION 225 "A unique identifier for an MPLS Tunnel. This may 226 represent an IPv4 address of the ingress or egress 227 LSR for the tunnel. This value is derived from the 228 Extended Tunnel Id in RSVP or the Ingress Router ID 229 for CR-LDP." 230 REFERENCE 231 "RSVP-TE: Extensions to RSVP for LSP Tunnels, 232 RFC 3209. 234 Constraint-Based LSP Setup using LDP, RFC 3212." 235 SYNTAX Unsigned32(0..4294967295) 237 MplsLabel ::= TEXTUAL-CONVENTION 238 STATUS current 239 DESCRIPTION 241 -- RFC-Editor, pls fill in RFCxxxx as assigned 242 -- to draft-ietf-ccamp-gmpls-architecture-07.txt." 244 "This value represents an MPLS label as defined in 245 (RFC3031), (RFC3032), (RFC3034), (RFC3035) and 246 (RFCxxxx). 248 The label contents are specific to the label being 249 represented, such as: 251 * The label carried in an MPLS shim header 252 (for LDP this is the Generic Label) is a 20-bit 253 number represented by 4 octets. Bits 0-19 contain 254 a label or a reserved label value. Bits 20-31 255 MUST be zero. 257 The following is quoted directly from (RFC3032). 258 There are several reserved label values: 260 i. A value of 0 represents the 261 'IPv4 Explicit NULL Label'. This label 262 value is only legal at the bottom of the 263 label stack. It indicates that the label 264 stack must be popped, and the forwarding 265 of the packet must then be based on the 266 IPv4 header. 268 ii. A value of 1 represents the 269 'Router Alert Label'. This label value is 270 legal anywhere in the label stack except at 271 the bottom. When a received packet 272 contains this label value at the top of 273 the label stack, it is delivered to a 274 local software module for processing. 275 The actual forwarding of the packet 276 is determined by the label beneath it 277 in the stack. However, if the packet is 278 forwarded further, the Router Alert Label 279 should be pushed back onto the label stack 280 before forwarding. The use of this label 281 is analogous to the use of the 282 'Router Alert Option' in IP packets 283 (RFC2113). Since this label 284 cannot occur at the bottom of the stack, 285 it is not associated with a 286 particular network layer protocol. 288 iii. A value of 2 represents the 289 'IPv6 Explicit NULL Label'. This label 290 value is only legal at the bottom of the 291 label stack. It indicates that the label 292 stack must be popped, and the forwarding 293 of the packet must then be based on the 294 IPv6 header. 296 iv. A value of 3 represents the 297 'Implicit NULL Label'. 298 This is a label that an LSR may assign and 299 distribute, but which never actually 300 appears in the encapsulation. When an 301 LSR would otherwise replace the label 302 at the top of the stack with a new label, 303 but the new label is 'Implicit NULL', 304 the LSR will pop the stack instead of 305 doing the replacement. Although 306 this value may never appear in the 307 encapsulation, it needs to be specified in 308 the Label Distribution Protocol, so a value 309 is reserved. 311 v. Values 4-15 are reserved. 313 * The frame relay label can be either 10-bits or 314 23-bits depending on the DLCI field size and the 315 upper 22-bits or upper 9-bits must be zero, 316 respectively. 318 * For an ATM label the lower 16-bits represents the 319 VCI, the next 12-bits represents the VPI and the 320 remaining bits MUST be zero. 322 * The Generalized-MPLS (GMPLS) label contains a 323 value greater than 2^24-1 and used in GMPLS 324 as defined in (RFCxxxx)." 325 -- RFC-Editor, pls fill in RFCxxxx as assigned 326 -- to draft-ietf-ccamp-gmpls-architecture-07.txt." 327 REFERENCE 328 "Multiprotocol Label Switching Architecture, 329 RFC3031. 331 MPLS Label Stack Encoding, RFC3032. 333 Use of Label Switching on Frame Relay Networks, 334 RFC3034. 336 MPLS using LDP and ATM VC Switching, RFC3035. 338 Generalized Multi-Protocol Label Switching 339 (GMPLS) Architecture, RFCxxxx." 340 -- RFC-Editor, pls fill in RFCxxxx as assigned 341 -- to draft-ietf-ccamp-gmpls-architecture-07.txt 342 SYNTAX Unsigned32 (0..4294967295) 344 MplsLabelDistributionMethod ::= TEXTUAL-CONVENTION 345 STATUS current 346 DESCRIPTION 347 "The label distribution method which is also called 348 the label advertisement mode (RFC3036). 349 Each interface on an LSR is configured to operate 350 in either Downstream Unsolicited or Downstream 351 on Demand." 352 REFERENCE 353 "Multiprotocol Label Switching Architecture, 354 RFC3031. 356 LDP Specification, RFC3036, Section 2.6.3." 357 SYNTAX INTEGER { 358 downstreamOnDemand(1), 359 downstreamUnsolicited(2) 360 } 362 MplsLdpIdentifier ::= TEXTUAL-CONVENTION 363 DISPLAY-HINT "1d.1d.1d.1d:2d" 364 STATUS current 365 DESCRIPTION 366 "The LDP identifier is a six octet 367 quantity which is used to identify a 368 Label Switching Router (LSR) label space. 370 The first four octets identify the LSR and 371 must be a globally unique value, such as a 372 32-bit router ID assigned to the LSR, and the 373 last two octets identify a specific label 374 space within the LSR." 375 SYNTAX OCTET STRING (SIZE (6)) 377 MplsLsrIdentifier ::= TEXTUAL-CONVENTION 378 STATUS current 379 DESCRIPTION 380 "The Label Switching Router (LSR) identifier is the 381 first 4 bytes of the Label Distribution Protocol 382 (LDP) identifier." 383 SYNTAX OCTET STRING (SIZE (4)) 385 MplsLdpLabelType ::= TEXTUAL-CONVENTION 386 STATUS current 387 DESCRIPTION 388 "The Layer 2 label types which are defined for MPLS 389 LDP and/or CR-LDP are generic(1), atm(2), or 390 frameRelay(3)." 391 SYNTAX INTEGER { 392 generic(1), 393 atm(2), 394 frameRelay(3) 395 } 397 MplsLSPID ::= TEXTUAL-CONVENTION 398 STATUS current 399 DESCRIPTION 400 "A unique identifier within an MPLS network that is 401 assigned to each LSP. This is assigned at the head 402 end of the LSP and can be used by all LSRs 403 to identify this LSP. This value is piggybacked by 404 the signaling protocol when this LSP is signaled 405 within the network. This identifier can then be 406 used at each LSR to identify which labels are 407 being swapped to other labels for this LSP. This 408 object can also be used to disambiguate LSPs that 409 share the same RSVP sessions between the same 410 source and destination. 412 For LSPs established using CR-LDP, the LSPID is 413 composed of the ingress LSR Router ID (or any of 414 its own IPv4 addresses) and a locally unique 415 CR-LSP ID to that LSR. The first two bytes carry 416 the CR-LSPID, and the remaining 4 bytes carry 417 the Router ID. The LSPID is useful in network 418 management, in CR-LSP repair, and in using 419 an already established CR-LSP as a hop in 420 an ER-TLV. 422 For LSPs signaled using RSVP-TE, the LSP ID is 423 defined as a 16-bit (2 byte) identifier used 424 in the SENDER_TEMPLATE and the FILTER_SPEC 425 that can be changed to allow a sender to 426 share resources with itself. The length of this 427 object should only be 2 or 6 bytes. If the length 428 of this octet string is 2 bytes, then it must 429 identify an RSVP-TE LSPID, or it is 6 bytes, 430 it must contain a CR-LDP LSPID." 432 REFERENCE 433 "RSVP-TE: Extensions to RSVP for LSP Tunnels, 434 RFC3209. 436 Constraint-Based LSP Setup using LDP, 437 RFC3212." 438 SYNTAX OCTET STRING (SIZE (2|6)) 440 MplsLspType ::= TEXTUAL-CONVENTION 441 STATUS current 442 DESCRIPTION 443 "Types of Label Switch Paths (LSPs) 444 on a Label Switching Router (LSR) or a 445 Label Edge Router (LER) are: 447 unknown(1) -- if the LSP is not known 448 to be one of the following. 450 terminatingLsp(2) -- if the LSP terminates 451 on the LSR/LER, then this 452 is an egressing LSP 453 which ends on the LSR/LER, 455 originatingLsp(3) -- if the LSP originates 456 from this LSR/LER, then 457 this is an ingressing LSP 458 which is the head-end of 459 the LSP, 461 crossConnectingLsp(4) -- if the LSP ingresses 462 and egresses on the LSR, 463 then it is 464 cross-connecting on that 465 LSR." 466 SYNTAX INTEGER { 467 unknown(1), 468 terminatingLsp(2), 469 originatingLsp(3), 470 crossConnectingLsp(4) 471 } 473 MplsOwner ::= TEXTUAL-CONVENTION 474 STATUS current 475 DESCRIPTION 476 "This object indicates the local network 477 management subsystem that originally created 478 the object(s) in question. The values of 479 this enumeration are defined as follows: 481 unknown(1) - the local network management 482 subsystem cannot discern which 483 component created the object. 485 other(2) - the local network management 486 subsystem is able to discern which component 487 created the object, but the component is not 488 listed within the following choices, 489 e.g. command line interface (cli). 491 snmp(3) - The Simple Network Management Protocol 492 was used to configure this object initially. 494 ldp(4) - The Label Distribution Protocol was 495 used to configure this object initially. 497 crldp(5) - The Constraint-Based Label Distribution 498 Protocol was used to configure this object 499 initially. 501 rsvpTe(6) - The Resource Reservation Protocol was 502 used to configure this object initially. 504 policyAgent(7) - A policy agent (perhaps in 505 combination with one of the above protocols) was 506 used to configure this object initially. 508 An object created by any of the above choices 509 MAY be modified or destroyed by the same or a 510 different choice." 511 SYNTAX INTEGER { 512 unknown(1), 513 other(2), 514 snmp(3), 515 ldp(4), 516 crldp(5), 517 rsvpTe(6), 518 policyAgent(7) 519 } 521 MplsPathIndexOrZero ::= TEXTUAL-CONVENTION 522 STATUS current 523 DESCRIPTION 524 "A unique identifier used to identify a specific 525 path used by a tunnel. A value of 0 (zero) means 526 that no path is in use." 527 SYNTAX Unsigned32(0..4294967295) 529 MplsPathIndex ::= TEXTUAL-CONVENTION 530 STATUS current 531 DESCRIPTION 532 "A unique value to index (by Path number) an 533 entry in a table." 534 SYNTAX Unsigned32(1..4294967295) 536 MplsRetentionMode ::= TEXTUAL-CONVENTION 537 STATUS current 538 DESCRIPTION 539 "The label retention mode which specifies whether 540 an LSR maintains a label binding for a FEC 541 learned from a neighbor that is not its next hop 542 for the FEC. 544 If the value is conservative(1) then advertised 545 label mappings are retained only if they will be 546 used to forward packets, i.e. if label came from 547 a valid next hop. 549 If the value is liberal(2) then all advertised 550 label mappings are retained whether they are from 551 a valid next hop or not." 552 REFERENCE 553 "Multiprotocol Label Switching Architecture, 554 RFC3031. 556 LDP Specification, RFC3036, Section 2.6.2." 557 SYNTAX INTEGER { 558 conservative(1), 559 liberal(2) 560 } 562 MplsTunnelAffinity ::= TEXTUAL-CONVENTION 563 STATUS current 564 DESCRIPTION 565 "Describes the configured 32-bit Include-any, 566 include-all, or exclude-all constraint for 567 constraint-based link selection." 568 REFERENCE 569 "RSVP-TE: Extensions to RSVP for LSP Tunnels, 570 RFC3209, Section 4.7.4." 571 SYNTAX Unsigned32(0..4294967295) 573 MplsTunnelIndex ::= TEXTUAL-CONVENTION 574 STATUS current 575 DESCRIPTION 576 "A unique index into mplsTunnelTable. 577 For tunnels signaled using RSVP, this value 578 should correspond to the RSVP destination 579 port used for the RSVP-TE session." 580 SYNTAX Unsigned32 (0..65535) 582 MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION 583 STATUS current 584 DESCRIPTION 585 "The tunnel entry with instance index 0 586 should refer to the configured tunnel 587 interface (if one exists). 589 Values greater than 0, but less than or 590 equal to 65535, should be used to indicate 591 signaled (or backup) tunnel LSP instances. 592 For tunnel LSPs signaled using RSVP, 593 this value should correspond to the 594 RSVP source port used for the RSVP-TE 595 session. 597 Values greater than 65535 apply to FRR 598 detour instances." 599 SYNTAX Unsigned32(0|1..65535|65536..4294967295) 601 TeHopAddressType ::= TEXTUAL-CONVENTION 602 STATUS current 603 DESCRIPTION 604 "A value that represents a type of address a 605 Traffic Engineered (TE) Tunnel hop. 607 unknown(0) An unknown address type. This value 608 MUST be used if the value of the 609 corresponding TeHopAddress object is a 610 zero-length string. It may also be 611 used to indicate a TeHopAddress which 612 is not in one of the formats defined 613 below. 615 ipv4(1) An IPv4 network address as defined by 616 the InetAddressIPv4 TEXTUAL-CONVENTION 617 (RFC3291). 619 ipv6(2) A global IPv6 address as defined by 620 the InetAddressIPv6 TEXTUAL-CONVENTION 621 (RFC3291). 623 asnumber(3) An Autonomous System (AS) number as 624 defined by the TeHopAddressAS 625 TEXTUAL-CONVENTION. 627 unnum(4) An unnumbered interface index as 628 defined by the TeHopAddressUnnum 629 TEXTUAL-CONVETION. 631 lspid(5) An LSP ID for CR-LDP Tunnels 632 (RFC3212) as defined by the 633 MplsLSPID TEXTUAL-CONVENTION. 635 Each definition of a concrete TeHopAddressType 636 value must be accompanied by a definition 637 of a textual convention for use with that 638 TeHopAddress. 640 To support future extensions, the TeHopAddressType 641 TEXTUAL-CONVENTION SHOULD NOT be sub-typed in 642 object type definitions. It MAY be sub-typed in 643 compliance statements in order to require only a 644 subset of these address types for a compliant 645 implementation. 647 Implementations must ensure that TeHopAddressType 648 objects and any dependent objects 649 (e.g. TeHopAddress objects) are consistent. 650 An inconsistentValue error must be generated 651 if an attempt to change a TeHopAddressType object 652 would, for example, lead to an undefined 653 TeHopAddress value. In particular, 654 TeHopAddressType/TeHopAddress pairs 655 must be changed together if the address type 656 changes (e.g. from ipv6(2) to ipv4(1))." 657 REFERENCE 658 "Textual Conventions for Internet Network 659 Addresses, RFC3291. 661 Constraint-Based LSP Setup using LDP, 662 RFC3212." 664 SYNTAX INTEGER { 665 unknown(0), 666 ipv4(1), 667 ipv6(2), 668 asnumber(3), 669 unnum(4), 670 lspid(5) 671 } 673 TeHopAddress ::= TEXTUAL-CONVENTION 674 STATUS current 675 DESCRIPTION 676 "Denotes a generic Tunnel hop address. 678 A TeHopAddress value is always interpreted within 679 the context of an TeHopAddressType value. Every 680 usage of the TeHopAddress TEXTUAL-CONVENTION 681 is required to specify the TeHopAddressType object 682 which provides the context. It is suggested that 683 the TeHopAddressType object is logically registered 684 before the object(s) which use the TeHopAddress 685 TEXTUAL-CONVENTION if they appear in the 686 same logical row. 688 The value of a TeHopAddress object must always be 689 consistent with the value of the associated 690 TeHopAddressType object. Attempts to set a 691 TeHopAddress object to a value which is 692 inconsistent with the associated TeHopAddressType 693 must fail with an inconsistentValue error." 694 SYNTAX OCTET STRING (SIZE (0..32)) 696 TeHopAddressAS ::= TEXTUAL-CONVENTION 697 STATUS current 698 DESCRIPTION 699 "Represents a two or four octet AS number. 700 The AS number is represented in network byte 701 order (MSB first). A two-octet AS number has 702 the two MSB octets set to zero." 704 REFERENCE 705 "Textual Conventions for Internet Network 706 Addresses, RFC3291. The 707 InetAutonomousSystemsNumber Textual Convention 708 has a SYNTAX of Unsigned32, whereas this TC 709 has a SYNTAX of OCTET STRING (SIZE (4)). 710 Both TCs represent an autonomous system number 711 but use different syntaxes to do so." 712 SYNTAX OCTET STRING (SIZE (4)) 714 TeHopAddressUnnum ::= TEXTUAL-CONVENTION 715 STATUS current 716 DESCRIPTION 717 "Represents an unnumbered interface: 719 octets contents encoding 720 1-4 unnumbered interface network-byte order 722 The corresponding TeHopAddressType value is 723 unnum(5)." 724 SYNTAX OCTET STRING(SIZE(4)) 726 END 728 4. Normative References 730 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 731 IANA Considerations Section in RFCs", BCP: 26, RFC 2434, 732 October 1998. 734 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 735 Rose, M. and S. Waldbusser, "Structure of Management 736 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 737 1999. 739 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 740 Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", 741 STD 58, RFC 2579, April 1999. 743 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 744 Rose, M. and S. Waldbusser, "Conformance Statements for 745 SMIv2", STD 58, RFC 2580, April 1999. 747 [RFC3031] Rosen, E., Viswananthan, A., and R. Callon, "Multiprotocol 748 Label Switching Architecture", RFC 3031, January 2001. 750 [RFC3032] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., 751 Federokow, G., Li, T., and A. Conta, "MPLS Label Stack 752 Encoding", RFC 3032, January 2001. 754 [RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching 755 on Frame Relay Networks Specification", RFC 3034, January 756 2001. 758 [RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, 759 G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC 760 Switching", RFC 3035, January 2001. 762 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. 763 Thomas, "LDP Specification", RFC 3036, January 2001. 765 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 766 Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", 767 RFC 3209, December 2001. 769 [RFC3212] Jamoussi, B., (editor), et. al. "Constraint-Based LSP Setup 770 using LDP", RFC 3212, January 2002. 772 [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. 773 Schoenwaelder, "Textual Conventions for Internet Network 774 Addresses", RFC 3291, May 2002. 776 [GMPLS-ARCH] 777 Mannie, E., (editor), et. al. "Generalized Multi-Protocol 778 Label Switching (GMPLS) Architecture", draft-ietf-ccamp- 779 gmpls-architecture-07.txt, May 2003. 781 5. Informative References 783 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 784 "Introduction and Applicability Statements for Internet- 785 Standard Management Framework", RFC 3410, December 2002. 787 6. Security Considerations 789 This module does not define any management objects. Instead, it 790 defines a set of textual conventions which may be used by other MPLS 791 MIB modules to define management objects. 793 Meaningful security considerations can only be written in the MIB 794 modules that define management objects. Therefore, this document has 795 no impact on the security of the Internet. 797 7. IANA Considerations 799 IANA is requested to make a MIB OID assignment under the transmission 800 branch, that is, assign the mplsStdMIB under { transmission 166 }. 801 This sub-id is requested because 166 is the ifType for mpls(166) and 802 is available under transmission. 804 In the future, MPLS related standards track MIB modules should be 805 rooted under the mplsStdMIB subtree. The IANA is requested to manage 806 that namespace. New assignments can only be made via a Standards 807 Action as specified in [RFC2434]. 809 This document also requests IANA to assign { mplsStdMIB 1 } to the 810 MPLS-TC-STD-MIB specified in this document. 812 8. Contributors 814 This document was created by combining TEXTUAL-CONVENTIONS from 815 current MPLS MIBs and a TE-WG MIB. Co-authors on each of these MIBs 816 contributed to the TEXTUAL-CONVENTIONS contained in this MIB and also 817 contributed greatly to the revisions of this document. These co- 818 authors addresses are included here because they are useful future 819 contacts for information about this document. These co-authors are: 821 Cheenu Srinivasan 822 Bloomberg L.P. 823 499 Park Ave. 824 New York, NY 10022 825 Phone: +1-212-893-3682 826 Email: cheenu@bloomberg.net 828 Arun Viswanathan 829 Force10 Networks, Inc. 830 1440 McCarthy Blvd 831 Milpitas, CA 95035 832 Phone: +1-408-571-3516 833 Email: arunv@force10networks.com 835 Hans Sjostrand 836 ipUnplugged 837 P.O. Box 101 60 838 S-121 28 Stockholm, Sweden 839 Phone: +46-8-725-5930 840 Email: hans@ipunplugged.com 842 Kireeti Kompella 843 Juniper Networks 844 1194 Mathilda Ave 845 Sunnyvale, CA 94089 846 Phone: +1-408-745-2000 847 Email: kireeti@juniper.net 849 9. Acknowledgements 851 This document is a product of the MPLS Working Group. The editors 852 and contributors would like to thank Mike MacFadden and Adrian Farrel 853 for their helpful comments on several reviews. Also, the editors and 854 contributors would like to give a special acknowledgement to Bert 855 Wijnen for his many detailed reviews. Bert's assistance and guidance 856 is greatly appreciated. 858 10. Intellectual Property Notice 860 The IETF takes no position regarding the validity or scope of any 861 intellectual property or other rights that might be claimed to 862 pertain to the implementation or use of the technology described in 863 this document or the extent to which any license under such rights 864 might or might not be available; neither does it represent that it 865 has made any effort to identify any such rights. Information on the 866 IETF's procedures with respect to rights in standards-track and 867 standards-related documentation can be found in BCP-11 [RFC2028]. 868 Copies of claims of rights made available for publication and any 869 assurances of licenses to be made available, or the result of an 870 attempt made to obtain a general license or permission for the use of 871 such proprietary rights by implementors or users of this 872 specification can be obtained from the IETF Secretariat. 874 The IETF invites any interested party to bring to its attention any 875 copyrights, patents or patent applications, or other proprietary 876 rights that may cover technology that may be required to practice 877 this standard. Please address the information to the IETF Executive 878 Director. 880 11. Authors' Addresses 882 Thomas D. Nadeau 883 Cisco Systems, Inc. 884 BXB300/2/ 885 300 Beaver Brook Road 886 Boxborough, MA 01719 887 Phone: +1-978-936-1470 888 Email: tnadeau@cisco.com 890 Joan Cucchiara 891 Artel 892 237 Cedar Hill Street 893 Marlborough, MA 01752 894 Phone: +1-508-303-8200 x302 895 Email: jcucchiara@artel.com 897 12. Full Copyright Statement 899 Copyright (C) The Internet Society (2003). All Rights Reserved. 901 This document and translations of it may be copied and furnished to 902 others, and derivative works that comment on or otherwise explain it 903 or assist in its implementation may be prepared, copied, published 904 and distributed, in whole or in part, without restriction of any 905 kind, provided that the above copyright notice and this paragraph are 906 included on all such copies and derivative works. However, this 907 document itself may not be modified in any way, such as by removing 908 the copyright notice or references to the Internet Society or other 909 Internet organizations, except as needed for the purpose of 910 developing Internet standards in which case the procedures for 911 copyrights defined in the Internet Standards process must be 912 followed, or as required to translate it into languages other than 913 English. 915 The limited permissions granted above are perpetual and will not be 916 revoked by the Internet Society or its successors or assigns. 918 This document and the information contained herein is provided on an 919 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 920 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 921 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 922 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 923 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.