idnits 2.17.1 draft-ietf-mpls-tc-mib-07.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 407 has weird spacing: '... object can a...' == Line 714 has weird spacing: '... octets cont...' == Line 715 has weird spacing: '...terface netw...' == Line 900 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 (June 2003) is 7619 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 745, but no explicit reference was found in the text == Unused Reference: 'RFC3034' is defined on line 749, but no explicit reference was found in the text == Unused Reference: 'RFC3035' is defined on line 753, but no explicit reference was found in the text == Unused Reference: 'RFC3036' is defined on line 757, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 760, but no explicit reference was found in the text == Unused Reference: 'RFC3212' is defined on line 764, but no explicit reference was found in the text == Unused Reference: 'RFC3291' is defined on line 767, but no explicit reference was found in the text == Unused Reference: 'GMPLS-ARCH' is defined on line 771, 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: December 2003 J. Cucchiara 4 Artel 5 (Editors) 7 June 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 "200306051200Z" -- 05 June 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 cheenu@alumni.princeton.edu 121 Arun Viswanathan 122 Force10 Networks, Inc. 123 arunv@force10networks.com 125 Hans Sjostrand 126 ipUnplugged 127 hans@ipunplugged.com 129 Kireeti Kompella 130 Juniper Networks 131 kireeti@juniper.net 133 Email comments to the MPLS WG Mailing List at 134 mpls@uu.net." 135 DESCRIPTION 136 "Copyright (C) The Internet Society (2003). This 137 version of this MIB module is part of RFCXXX; see 138 the RFC itself for full legal notices. 140 This MIB module defines Textual Conventions 141 for concepts used in Multi-Protocol Label 142 Switching (MPLS) networks." 144 REVISION "200306051200Z" -- 05 June 2003 12:00:00 GMT 145 DESCRIPTION 146 "Initial version published as part of RFC XXXX." 148 -- Please see the IANA Considerations Section. 149 -- The requested mplsStdMIB subId is 1, e.g. 150 -- ::= { mplsStdMIB 1 } 152 ::= { mplsStdMIB XXX } -- to be assigned by IANA 154 mplsStdMIB OBJECT IDENTIFIER 156 -- This object identifier needs to be assigned by IANA. 157 -- Since mpls has been assigned an ifType of 166 we recommend 158 -- that this OID be 166 as well, e.g. 159 -- ::= { transmission 166 } 161 ::= { transmission XXX } -- to be assigned by IANA 163 MplsAtmVcIdentifier ::= TEXTUAL-CONVENTION 164 DISPLAY-HINT "d" 165 STATUS current 166 DESCRIPTION 167 "A Label Switching Router (LSR) that 168 creates LDP sessions on ATM interfaces 169 uses the VCI or VPI/VCI field to hold the 170 LDP Label. 172 VCI values MUST NOT be in the 0-31 range. 173 The values 0 to 31 are reserved for other uses 174 by the ITU and ATM Forum. The value 175 of 32 can only be used for the Control VC, 176 although values greater than 32 could be 177 configured for the Control VC. 179 If a value from 0 to 31 is used for a VCI 180 the management entity controlling the LDP 181 subsystem should reject this with an 182 inconsistentValue error. Also, if 183 the value of 32 is used for a VC which is 184 NOT the Control VC, this should 185 result in an inconsistentValue error." 186 REFERENCE 187 "MPLS using LDP and ATM VC Switching, RFC3035." 188 SYNTAX Integer32 (32..65535) 190 MplsBitRate ::= TEXTUAL-CONVENTION 191 DISPLAY-HINT "d" 192 STATUS current 193 DESCRIPTION 194 "If the value of this object is greater than zero, 195 then this represents the bandwidth of this MPLS 196 interface (or Label Switched Path) in units of 197 '1,000 bits per second'. 199 The value, when greater than zero, represents the 200 bandwidth of this MPLS interface (rounded to the 201 nearest 1,000) in units of 1,000 bits per second. 202 If the bandwidth of the MPLS interface is between 203 ((n * 1000) - 500) and ((n * 1000) + 499), the value 204 of this object is n, such that n > 0. 206 If the value of this object is 0 (zero), this 207 means that the traffic over this MPLS interface is 208 considered to be best effort." 209 SYNTAX Unsigned32 (0|1..4294967295) 211 MplsBurstSize ::= TEXTUAL-CONVENTION 212 DISPLAY-HINT "d" 213 STATUS current 214 DESCRIPTION 215 "The number of octets of MPLS data that the stream 216 may send back-to-back without concern for policing. 217 The value of zero indicates that an implementation 218 does not support Burst Size." 219 SYNTAX Unsigned32 (0..4294967295) 221 MplsExtendedTunnelId ::= TEXTUAL-CONVENTION 222 STATUS current 223 DESCRIPTION 224 "A unique identifier for an MPLS Tunnel. This may 225 represent an IPv4 address of the ingress or egress 226 LSR for the tunnel. This value is derived from the 227 Extended Tunnel Id in RSVP or the Ingress Router ID 228 for CR-LDP." 229 REFERENCE 230 "RSVP-TE: Extensions to RSVP for LSP Tunnels, 231 RFC 3209. 233 Constraint-Based LSP Setup using LDP, RFC 3212." 234 SYNTAX Unsigned32 236 MplsLabel ::= TEXTUAL-CONVENTION 237 STATUS current 238 DESCRIPTION 240 -- RFC-Editor, pls fill in RFCxxxx as assigned 241 -- to draft-ietf-ccamp-gmpls-architecture-07.txt." 243 "This value represents an MPLS label as defined in 244 (RFC3031), (RFC3032), (RFC3034), (RFC3035) and 245 (RFCxxxx). 247 The label contents are specific to the label being 248 represented, such as: 250 * The label carried in an MPLS shim header 251 (for LDP this is the Generic Label) is a 20-bit 252 number represented by 4 octets. Bits 0-19 contain 253 a label or a reserved label value. Bits 20-31 254 MUST be zero. 256 The following is quoted directly from (RFC3032). 257 There are several reserved label values: 259 i. A value of 0 represents the 260 'IPv4 Explicit NULL Label'. This label 261 value is only legal at the bottom of the 262 label stack. It indicates that the label 263 stack must be popped, and the forwarding 264 of the packet must then be based on the 265 IPv4 header. 267 ii. A value of 1 represents the 268 'Router Alert Label'. This label value is 269 legal anywhere in the label stack except at 270 the bottom. When a received packet 271 contains this label value at the top of 272 the label stack, it is delivered to a 273 local software module for processing. 274 The actual forwarding of the packet 275 is determined by the label beneath it 276 in the stack. However, if the packet is 277 forwarded further, the Router Alert Label 278 should be pushed back onto the label stack 279 before forwarding. The use of this label 280 is analogous to the use of the 281 'Router Alert Option' in IP packets 282 (RFC2113). Since this label 283 cannot occur at the bottom of the stack, 284 it is not associated with a 285 particular network layer protocol. 287 iii. A value of 2 represents the 288 'IPv6 Explicit NULL Label'. This label 289 value is only legal at the bottom of the 290 label stack. It indicates that the label 291 stack must be popped, and the forwarding 292 of the packet must then be based on the 293 IPv6 header. 295 iv. A value of 3 represents the 296 'Implicit NULL Label'. 297 This is a label that an LSR may assign and 298 distribute, but which never actually 299 appears in the encapsulation. When an 300 LSR would otherwise replace the label 301 at the top of the stack with a new label, 302 but the new label is 'Implicit NULL', 303 the LSR will pop the stack instead of 304 doing the replacement. Although 305 this value may never appear in the 306 encapsulation, it needs to be specified in 307 the Label Distribution Protocol, so a value 308 is reserved. 310 v. Values 4-15 are reserved. 312 * The frame relay label can be either 10-bits or 313 23-bits depending on the DLCI field size and the 314 upper 22-bits or upper 9-bits must be zero, 315 respectively. 317 * For an ATM label the lower 16-bits represents the 318 VCI, the next 12-bits represents the VPI and the 319 remaining bits MUST be zero. 321 * The Generalized-MPLS (GMPLS) label contains a 322 value greater than 2^24-1 and used in GMPLS 323 as defined in (RFCxxxx)." 324 -- RFC-Editor, pls fill in RFCxxxx as assigned 325 -- to draft-ietf-ccamp-gmpls-architecture-07.txt." 326 REFERENCE 327 "Multiprotocol Label Switching Architecture, 328 RFC3031. 330 MPLS Label Stack Encoding, RFC3032. 332 Use of Label Switching on Frame Relay Networks, 333 RFC3034. 335 MPLS using LDP and ATM VC Switching, RFC3035. 337 Generalized Multi-Protocol Label Switching 338 (GMPLS) Architecture, RFCxxxx." 339 -- RFC-Editor, pls fill in RFCxxxx as assigned 340 -- to draft-ietf-ccamp-gmpls-architecture-07.txt 341 SYNTAX Unsigned32 (0..4294967295) 343 MplsLabelDistributionMethod ::= TEXTUAL-CONVENTION 344 STATUS current 345 DESCRIPTION 346 "The label distribution method which is also called 347 the label advertisement mode (RFC3036). 348 Each interface on an LSR is configured to operate 349 in either Downstream Unsolicited or Downstream 350 on Demand." 351 REFERENCE 352 "Multiprotocol Label Switching Architecture, 353 RFC3031. 355 LDP Specification, RFC3036, Section 2.6.3." 356 SYNTAX INTEGER { 357 downstreamOnDemand(1), 358 downstreamUnsolicited(2) 359 } 361 MplsLdpIdentifier ::= TEXTUAL-CONVENTION 362 DISPLAY-HINT "1d.1d.1d.1d:2d" 363 STATUS current 364 DESCRIPTION 365 "The LDP identifier is a six octet 366 quantity which is used to identify a 367 Label Switching Router (LSR) label space. 369 The first four octets identify the LSR and 370 must be a globally unique value, such as a 371 32-bit router ID assigned to the LSR, and the 372 last two octets identify a specific label 373 space within the LSR." 374 SYNTAX OCTET STRING (SIZE (6)) 376 MplsLsrIdentifier ::= TEXTUAL-CONVENTION 377 STATUS current 378 DESCRIPTION 379 "The Label Switching Router (LSR) identifier is the 380 first 4 bytes of the Label Distribution Protocol 381 (LDP) identifier." 382 SYNTAX OCTET STRING (SIZE (4)) 384 MplsLdpLabelType ::= TEXTUAL-CONVENTION 385 STATUS current 386 DESCRIPTION 387 "The Layer 2 label types which are defined for MPLS 388 LDP and/or CR-LDP are generic(1), atm(2), or 389 frameRelay(3)." 390 SYNTAX INTEGER { 391 generic(1), 392 atm(2), 393 frameRelay(3) 394 } 396 MplsLSPID ::= TEXTUAL-CONVENTION 397 STATUS current 398 DESCRIPTION 399 "A unique identifier within an MPLS network that is 400 assigned to each LSP. This is assigned at the head 401 end of the LSP and can be used by all LSRs 402 to identify this LSP. This value is piggybacked by 403 the signaling protocol when this LSP is signaled 404 within the network. This identifier can then be 405 used at each LSR to identify which labels are 406 being swapped to other labels for this LSP. This 407 object can also be used to disambiguate LSPs that 408 share the same RSVP sessions between the same 409 source and destination. 411 For LSPs established using CR-LDP, the LSPID is 412 composed of the ingress LSR Router ID (or any of 413 its own IPv4 addresses) and a locally unique 414 CR-LSP ID to that LSR. The first two bytes carry 415 the CR-LSPID, and the remaining 4 bytes carry 416 the Router ID. The LSPID is useful in network 417 management, in CR-LSP repair, and in using 418 an already established CR-LSP as a hop in 419 an ER-TLV. 421 For LSPs signaled using RSVP-TE, the LSP ID is 422 defined as a 16-bit (2 byte) identifier used 423 in the SENDER_TEMPLATE and the FILTER_SPEC 424 that can be changed to allow a sender to 425 share resources with itself. The length of this 426 object should only be 2 or 6 bytes. If the length 427 of this octet string is 2 bytes, then it must 428 identify an RSVP-TE LSPID, or it is 6 bytes, 429 it must contain a CR-LDP LSPID." 431 REFERENCE 432 "RSVP-TE: Extensions to RSVP for LSP Tunnels, 433 RFC3209. 435 Constraint-Based LSP Setup using LDP, 436 RFC3212." 437 SYNTAX OCTET STRING (SIZE (2|6)) 439 MplsLspType ::= TEXTUAL-CONVENTION 440 STATUS current 441 DESCRIPTION 442 "Types of Label Switch Paths (LSPs) 443 on a Label Switching Router (LSR) or a 444 Label Edge Router (LER) are: 446 unknown(1) -- if the LSP is not known 447 to be one of the following. 449 terminatingLsp(2) -- if the LSP terminates 450 on the LSR/LER, then this 451 is an egressing LSP 452 which ends on the LSR/LER, 454 originatingLsp(3) -- if the LSP originates 455 from this LSR/LER, then 456 this is an ingressing LSP 457 which is the head-end of 458 the LSP, 460 crossConnectingLsp(4) -- if the LSP ingresses 461 and egresses on the LSR, 462 then it is 463 cross-connecting on that 464 LSR." 465 SYNTAX INTEGER { 466 unknown(1), 467 terminatingLsp(2), 468 originatingLsp(3), 469 crossConnectingLsp(4) 470 } 472 MplsOwner ::= TEXTUAL-CONVENTION 473 STATUS current 474 DESCRIPTION 475 "This object indicates the local network 476 management subsystem that originally created 477 the object(s) in question. The values of 478 this enumeration are defined as follows: 480 unknown(1) - the local network management 481 subsystem cannot discern which 482 component created the object. 484 other(2) - the local network management 485 subsystem is able to discern which component 486 created the object, but the component is not 487 listed within the following choices, 488 e.g. command line interface (cli). 490 snmp(3) - The Simple Network Management Protocol 491 was used to configure this object initially. 493 ldp(4) - The Label Distribution Protocol was 494 used to configure this object initially. 496 crldp(5) - The Constraint-Based Label Distribution 497 Protocol was used to configure this object 498 initially. 500 rsvpTe(6) - The Resource Reservation Protocol was 501 used to configure this object initially. 503 policyAgent(7) - A policy agent (perhaps in 504 combination with one of the above protocols) was 505 used to configure this object initially. 507 An object created by any of the above choices 508 MAY be modified or destroyed by the same or a 509 different choice." 510 SYNTAX INTEGER { 511 unknown(1), 512 other(2), 513 snmp(3), 514 ldp(4), 515 crldp(5), 516 rsvpTe(6), 517 policyAgent(7) 518 } 520 MplsPathIndexOrZero ::= TEXTUAL-CONVENTION 521 STATUS current 522 DESCRIPTION 523 "A unique identifier used to identify a specific 524 path used by a tunnel. A value of 0 (zero) means 525 that no path is in use." 526 SYNTAX Unsigned32 528 MplsPathIndex ::= TEXTUAL-CONVENTION 529 STATUS current 530 DESCRIPTION 531 "A unique value to index (by Path number) an 532 entry in a table." 533 SYNTAX Unsigned32(1..4294967295) 535 MplsRetentionMode ::= TEXTUAL-CONVENTION 536 STATUS current 537 DESCRIPTION 538 "The label retention mode which specifies whether 539 an LSR maintains a label binding for a FEC 540 learned from a neighbor that is not its next hop 541 for the FEC. 543 If the value is conservative(1) then advertised 544 label mappings are retained only if they will be 545 used to forward packets, i.e. if label came from 546 a valid next hop. 548 If the value is liberal(2) then all advertised 549 label mappings are retained whether they are from 550 a valid next hop or not." 551 REFERENCE 552 "Multiprotocol Label Switching Architecture, 553 RFC3031. 555 LDP Specification, RFC3036, Section 2.6.2." 556 SYNTAX INTEGER { 557 conservative(1), 558 liberal(2) 559 } 561 MplsTunnelAffinity ::= TEXTUAL-CONVENTION 562 STATUS current 563 DESCRIPTION 564 "Describes the configured 32-bit Include-any, 565 include-all, or exclude-all constraint for 566 constraint-based link selection." 567 REFERENCE 568 "RSVP-TE: Extensions to RSVP for LSP Tunnels, 569 RFC3209, Section 4.7.4." 570 SYNTAX Unsigned32 572 MplsTunnelIndex ::= TEXTUAL-CONVENTION 573 STATUS current 574 DESCRIPTION 575 "A unique index into mplsTunnelTable. 576 For tunnels signaled using RSVP, this value 577 should correspond to the RSVP destination 578 port used for the RSVP-TE session." 579 SYNTAX Unsigned32 (0..65535) 581 MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION 582 STATUS current 583 DESCRIPTION 584 "Instance index into mplsTunnelTable. The 585 tunnel entry with instance index 0 should 586 refer to the configured tunnel interface 587 (if one exists), and values greater an 0 but 588 less than or equal to 65535 589 should be used to indicate signaled (or backup) 590 tunnel LSP instances. For tunnel LSPs signaled 591 using RSVP, this value should correspond to the 592 RSVP source port used for the RSVP-TE session. 594 Values greater than 65535 apply to FRR detour 595 instances." 596 SYNTAX Unsigned32 598 TeHopAddressType ::= TEXTUAL-CONVENTION 599 STATUS current 600 DESCRIPTION 601 "A value that represents a type of address a 602 Traffic Engineered (TE) Tunnel hop. 604 unknown(0) An unknown address type. This value 605 MUST be used if the value of the 606 corresponding TeHopAddress object is a 607 zero-length string. It may also be 608 used to indicate a TeHopAddress which 609 is not in one of the formats defined 610 below. 612 ipv4(1) An IPv4 network address as defined by 613 the InetAddressIPv4 TEXTUAL-CONVENTION 614 (RFC3291). 616 ipv6(2) A global IPv6 address as defined by 617 the InetAddressIPv6 TEXTUAL-CONVENTION 618 (RFC3291). 620 asnumber(3) An Autonomous System (AS) number as 621 defined by the TeHopAddressAS 622 TEXTUAL-CONVENTION. 624 unnum(4) An unnumbered interface index as 625 defined by the TeHopAddressUnnum 626 TEXTUAL-CONVETION. 628 lspid(5) An LSP ID for CR-LDP Tunnels 629 (RFC3212) as defined by the 630 MplsLSPID TEXTUAL-CONVENTION. 632 Each definition of a concrete TeHopAddress value 633 must be accompanied by a definition of a textual 634 convention for use with that TeHopAddressType. 636 To support future extensions, the TeHopAddressType 637 TEXTUAL-CONVENTION SHOULD NOT be sub-typed in 638 object type definitions. It MAY be sub-typed in 639 compliance statements in order to require only a 640 subset of these address types for a compliant 641 implementation. 643 Implementations must ensure that TeHopAddressType 644 objects and any dependent objects 645 (e.g. TeHopAddress objects) are consistent. 646 An inconsistentValue error must be generated 647 if an attempt to change a TeHopAddressType object 648 would, for example, lead to an undefined 649 TeHopAddress value. In particular, 650 TeHopAddressType/TeHopAddress pairs 651 must be changed together if the address type 652 changes (e.g. from ipv6(3) to ipv4(2))." 653 REFERENCE 654 "Textual Conventions for Internet Network 655 Addresses, RFC3291. 657 Constraint-Based LSP Setup using LDP, 658 RFC3212." 660 SYNTAX INTEGER { 661 unknown(0), 662 ipv4(1), 663 ipv6(2), 664 asnumber(3), 665 unnum(4), 666 lspid(5) 667 } 669 TeHopAddress ::= TEXTUAL-CONVENTION 670 STATUS current 671 DESCRIPTION 672 "Denotes a generic Tunnel hop address. 674 A TeHopAddress value is always interpreted within 675 the context of an TeHopAddressType value. Every 676 usage of the TeHopInetAddress TEXTUAL-CONVENTION 677 is required to specify the TeHopAddressType object 678 which provides the context. It is suggested that 679 the TeHopAddressType object is logically registered 680 before the object(s) which use the TeHopAddress 681 TEXTUAL-CONVENTION if they appear in the 682 same logical row. 684 The value of a TeHopAddress object must always be 685 consistent with the value of the associated 686 TeHopAddressType object. Attempts to set a 687 TeHopAddress object to a value which is 688 inconsistent with the associated TeHopAddressType 689 must fail with an inconsistentValue error." 690 SYNTAX OCTET STRING (SIZE (0..32)) 692 TeHopAddressAS ::= TEXTUAL-CONVENTION 693 STATUS current 694 DESCRIPTION 695 "Represents a two or four octet AS number. 696 The AS number is represented in network byte 697 order (MSB first). A two-octet AS number has 698 the two MSB octets set to zero." 699 REFERENCE 700 "Textual Conventions for Internet Network 701 Addresses, RFC3291. The 702 InetAutonomousSystemsNumber Textual Convention 703 has a SYNTAX of Unsigned32, whereas this TC 704 has a SYNTAX of OCTET STRING (SIZE (4)). 705 Both TCs represent an autonomous system number 706 but use different syntaxes to do so." 707 SYNTAX OCTET STRING (SIZE (4)) 709 TeHopAddressUnnum ::= TEXTUAL-CONVENTION 710 STATUS current 711 DESCRIPTION 712 "Represents an unnumbered interface: 714 octets contents encoding 715 1-4 unnumbered interface network-byte order 717 The corresponding TeHopAddressType value is 718 unnum(5)." 719 SYNTAX OCTET STRING(SIZE(4)) 721 END 723 4. Normative References 725 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 726 IANA Considerations Section in RFCs", BCP: 26, RFC 2434, 727 October 1998. 729 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 730 Rose, M. and S. Waldbusser, "Structure of Management 731 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 732 1999. 734 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 735 Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", 736 STD 58, RFC 2579, April 1999. 738 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 739 Rose, M. and S. Waldbusser, "Conformance Statements for 740 SMIv2", STD 58, RFC 2580, April 1999. 742 [RFC3031] Rosen, E., Viswananthan, A., and R. Callon, "Multiprotocol 743 Label Switching Architecture", RFC 3031, January 2001. 745 [RFC3032] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., 746 Federokow, G., Li, T., and A. Conta, "MPLS Label Stack 747 Encoding", RFC 3032, January 2001. 749 [RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching 750 on Frame Relay Networks Specification", RFC 3034, January 751 2001. 753 [RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, 754 G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC 755 Switching", RFC 3035, January 2001. 757 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. 758 Thomas, "LDP Specification", RFC 3036, January 2001. 760 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 761 Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", 762 RFC 3209, December 2001. 764 [RFC3212] Jamoussi, B., (editor), et. al. "Constraint-Based LSP Setup 765 using LDP", RFC 3212, January 2002. 767 [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. 768 Schoenwaelder, "Textual Conventions for Internet Network 769 Addresses", RFC 3291, May 2002. 771 [GMPLS-ARCH] 772 Mannie, E., (editor), et. al. "Generalized Multi-Protocol 773 Label Switching (GMPLS) Architecture", draft-ietf-ccamp- 774 gmpls-architecture-07.txt, May 2003. 776 5. Informative References 778 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 779 "Introduction and Applicability Statements for Internet- 780 Standard Management Framework", RFC 3410, December 2002. 782 6. Security Considerations 784 This module does not define any management objects. Instead, it 785 defines a set of textual conventions which may be used by other MPLS 786 MIB modules to define management objects. 788 Meaningful security considerations can only be written in the MIB 789 modules that define management objects. Therefore, this document has 790 no impact on the security of the Internet. 792 7. IANA Considerations 794 IANA is requested to make a MIB OID assignment under the transmission 795 branch, that is, assign the mplsStdMIB under { transmission 166 }. 796 This sub-id is requested because 166 is the ifType for mpls(166) and 797 is available under transmission. 799 In the future, MPLS related standards track MIB modules should be 800 rooted under the mplsStdMIB subtree. The IANA is requested to manage 801 that namespace. New assignments can only be made via a Standards 802 Action as specified in [RFC2434]. 804 This document also requests IANA to assign { mplsStdMIB 1 } to the 805 MPLS-TC-STD-MIB specified in this document. 807 8. Contributors 809 This document was created by combining TEXTUAL-CONVENTIONS from 810 current MPLS MIBs and a TE-WG MIB. Co-authors on each of these MIBs 811 contributed to the TEXTUAL-CONVENTIONS contained in this MIB and also 812 contributed greatly to the revisions of this document. These co- 813 authors addresses are included here because they are useful future 814 contacts for information about this document. These co-authors are: 816 Cheenu Srinivasan 817 Email: cheenu@alumni.princeton.edu 819 Arun Viswanathan 820 Force10 Networks, Inc. 821 1440 McCarthy Blvd 822 Milpitas, CA 95035 823 Phone: +1-408-571-3516 824 Email: arunv@force10networks.com 826 Hans Sjostrand 827 ipUnplugged 828 P.O. Box 101 60 829 S-121 28 Stockholm, Sweden 830 Phone: +46-8-725-5930 831 Email: hans@ipunplugged.com 833 Kireeti Kompella 834 Juniper Networks 835 1194 Mathilda Ave 836 Sunnyvale, CA 94089 837 Phone: +1-408-745-2000 838 Email: kireeti@juniper.net 840 9. Acknowledgements 842 This document is a product of the MPLS Working Group. The editors 843 and contributors would like to thank Mike MacFadden and Adrian Farrel 844 for their helpful comments on several reviews. Also, the editors and 845 contributors would like to give a special acknowledgement to Bert 846 Wijnen for his many detailed reviews. Bert's assistance and guidance 847 is greatly appreciated. 849 10. Intellectual Property Notice 851 The IETF takes no position regarding the validity or scope of any 852 intellectual property or other rights that might be claimed to 853 pertain to the implementation or use of the technology described in 854 this document or the extent to which any license under such rights 855 might or might not be available; neither does it represent that it 856 has made any effort to identify any such rights. Information on the 857 IETF's procedures with respect to rights in standards-track and 858 standards-related documentation can be found in BCP-11 [RFC2028]. 859 Copies of claims of rights made available for publication and any 860 assurances of licenses to be made available, or the result of an 861 attempt made to obtain a general license or permission for the use of 862 such proprietary rights by implementors or users of this 863 specification can be obtained from the IETF Secretariat. 865 The IETF invites any interested party to bring to its attention any 866 copyrights, patents or patent applications, or other proprietary 867 rights that may cover technology that may be required to practice 868 this standard. Please address the information to the IETF Executive 869 Director. 871 11. Authors' Addresses 873 Thomas D. Nadeau 874 Cisco Systems, Inc. 875 BXB300/2/ 876 300 Beaver Brook Road 877 Boxborough, MA 01719 878 Phone: +1-978-936-1470 879 Email: tnadeau@cisco.com 881 Joan Cucchiara 882 Artel 883 237 Cedar Hill Street 884 Marlborough, MA 01752 885 Phone: +1-508-303-8200 x302 886 Email: jcucchiara@artel.com 888 12. Full Copyright Statement 890 Copyright (C) The Internet Society (2003). All Rights Reserved. 892 This document and translations of it may be copied and furnished to 893 others, and derivative works that comment on or otherwise explain it 894 or assist in its implementation may be prepared, copied, published 895 and distributed, in whole or in part, without restriction of any 896 kind, provided that the above copyright notice and this paragraph are 897 included on all such copies and derivative works. However, this 898 document itself may not be modified in any way, such as by removing 899 the copyright notice or references to the Internet Society or other 900 Internet organizations, except as needed for the purpose of 901 developing Internet standards in which case the procedures for 902 copyrights defined in the Internet Standards process must be 903 followed, or as required to translate it into languages other than 904 English. 906 The limited permissions granted above are perpetual and will not be 907 revoked by the Internet Society or its successors or assigns. 909 This document and the information contained herein is provided on an 910 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 911 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 912 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 913 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 914 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.