idnits 2.17.1 draft-manral-mpls-rfc3811bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 400 has weird spacing: '... object can a...' == Line 680 has weird spacing: '...n which case ...' == Line 722 has weird spacing: '... octets cont...' == Line 723 has weird spacing: '...terface netw...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 20, 2013) is 3994 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) ** 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: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force V. Manral 3 Internet-Draft Hewlett-Packard Corp. 4 Obsoletes: 3811 (if approved) T. Tsou 5 Intended status: Standards Track Huawei Technologies (USA) 6 Expires: November 21, 2013 W. Liu 7 Huawei Technologies 8 May 20, 2013 10 Definitions of Textual Conventions (TCs) for Multiprotocol Label 11 Switching (MPLS) Management 12 draft-manral-mpls-rfc3811bis-02 14 Abstract 16 This memo defines a Management Information Base (MIB) module which 17 contains Textual Conventions to represent commonly used Multiprotocol 18 Label Switching (MPLS) management information. The intent is that 19 these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS 20 related MIB modules that would otherwise define their own 21 representations. 23 This document obsoletes RFC3811 as it addresses the need to support 24 IPv6 extended TunnelID's by defining a new TC- 25 MplsNewExtendedTunnelID which suggests using IPv4 address of the 26 ingress or egress LSR for the tunnel for an IPv6 network. Changes 27 from RFC3811 and the effect of the new TC to other related documents 28 are summarized in Section 4 and 5, respectively. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on November 21, 2013. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 76 2. The Internet-Standard Management Framework . . . . . . . . . 3 77 3. MPLS Textual Conventions MIB Definitions . . . . . . . . . . 3 78 4. Changes from RFC3811 . . . . . . . . . . . . . . . . . . . . 16 79 5. Effect of the new TC . . . . . . . . . . . . . . . . . . . . 17 80 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 86 10.2. Informative References . . . . . . . . . . . . . . . . . 21 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 89 1. Introduction 91 This document defines a MIB module which contains Textual Conventions 92 (TCs) for Multiprotocol Label Switching (MPLS) networks. These 93 Textual Conventions should be imported by MIB modules which manage 94 MPLS networks. The need to support IPv6 extended TunnelID's is 95 addressed by defining a new TC-MplsNewExtendedTunnelID which may 96 represent an IPv4 address of the ingress or egress LSR for the tunnel 97 for an IPv4 network or an IPv6 network. 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 For an introduction to the concepts of MPLS, see [RFC3031]. 105 2. The Internet-Standard Management Framework 107 For a detailed overview of the documents that describe the current 108 Internet-Standard Management Framework, please refer to Section 7 of 109 [RFC3410]. 111 Managed objects are accessed via a virtual information store, termed 112 the Management Information Base or MIB. MIB objects are generally 113 accessed through the Simple Network Management Protocol (SNMP). 114 Objects in the MIB are defined using the mechanisms defined in the 115 Structure of Management Information (SMI). This memo specifies a MIB 116 module that is compliant to the SMIv2, which is described in STD 58 117 ([RFC2578], [RFC2579], and [RFC2580]). 119 3. MPLS Textual Conventions MIB Definitions 121 MPLS-TC-STD-MIB DEFINITIONS ::= BEGIN 123 IMPORTS 125 MODULE-IDENTITY, 126 Unsigned32, Integer32, 127 transmission FROM SNMPv2-SMI -- [RFC2578] 129 TEXTUAL-CONVENTION 130 FROM SNMPv2-TC; -- [RFC2579] 132 mplsTCStdMIB MODULE-IDENTITY 133 LAST-UPDATED "200406030000Z" -- June 3, 2004 134 ORGANIZATION 135 "IETF Multiprotocol Label Switching (MPLS) Working 136 Group." 137 CONTACT-INFO 138 " Vishwas Manral 139 Hewlett-Packard Corp. 141 Email comments to the MPLS WG Mailing List at 142 mpls@uu.net." 143 DESCRIPTION 144 "Copyright (C) The Internet Society (2008). The 145 initial version of this MIB module was published 146 in Internet Draft. For full legal notices see the RFC 147 itself or see: 148 http://www.ietf.org/copyrights/ianamib.html 150 This MIB module defines TEXTUAL-CONVENTIONs 151 for concepts used in Multiprotocol Label 152 Switching (MPLS) networks. 154 Changes from RFC3811 - MplsExtendedTunnelId" 156 REVISION "200809080000Z" -- 8 September, 2008 157 DESCRIPTION 158 "Initial version published as part of Internet Draft. To be 159 published as RFC XXXX" 160 -- RFC Ed.: RFC-editor pleases fill in XXXX 161 ::= { mplsStdMIB 1 } 163 mplsStdMIB OBJECT IDENTIFIER 165 ::= { transmission 166 } 167 MplsAtmVcIdentifier ::= TEXTUAL-CONVENTION 168 DISPLAY-HINT "d" 169 STATUS current 170 DESCRIPTION 171 "A Label Switching Router (LSR) that 172 creates LDP sessions on ATM interfaces 173 uses the VCI or VPI/VCI field to hold the 174 LDP Label. 176 VCI values MUST NOT be in the 0-31 range. 177 The values 0 to 31 are reserved for other uses 178 by the ITU and ATM Forum. The value 179 of 32 can only be used for the Control VC, 180 although values greater than 32 could be 181 configured for the Control VC. 183 If a value from 0 to 31 is used for a VCI, 184 the management entity controlling the LDP 185 subsystem should reject this with an 186 inconsistentValue error. Also, if 187 the value of 32 is used for a VC which is 188 NOT the Control VC, this should 189 result in an inconsistentValue error." 190 REFERENCE 191 "MPLS using LDP and ATM VC Switching, RFC3035." 192 SYNTAX Integer32 (32..65535) 194 MplsBitRate ::= TEXTUAL-CONVENTION 195 DISPLAY-HINT "d" 196 STATUS current 197 DESCRIPTION 198 "If the value of this object is greater than zero, 199 then this represents the bandwidth of this MPLS 200 interface (or Label Switched Path) in units of 201 '1,000 bits per second'. 203 The value, when greater than zero, represents the 204 bandwidth of this MPLS interface (rounded to the 205 nearest 1,000) in units of 1,000 bits per second. 206 If the bandwidth of the MPLS interface is between 207 ((n * 1000) - 500) and ((n * 1000) + 499), the value 208 of this object is n, such that n > 0. 210 If the value of this object is 0 (zero), this 211 means that the traffic over this MPLS interface is 212 considered to be best effort." 213 SYNTAX Unsigned32 (0|1..4294967295) 215 MplsBurstSize ::= TEXTUAL-CONVENTION 216 DISPLAY-HINT "d" 217 STATUS current 218 DESCRIPTION 219 "The number of octets of MPLS data that the stream 220 may send back-to-back without concern for policing. 221 The value of zero indicates that an implementation 222 does not support Burst Size." 223 SYNTAX Unsigned32 (0..4294967295) 225 MplsExtendedTunnelId ::= TEXTUAL-CONVENTION 226 STATUS obsolete 227 DESCRIPTION 228 "A unique identifier for an MPLS Tunnel. This may 229 represent an IPv4 address of the ingress or egress 230 LSR for the tunnel. This value is derived from the 231 Extended Tunnel Id in RSVP or the Ingress Router ID 232 for CR-LDP." 233 REFERENCE 234 "RSVP-TE: Extensions to RSVP for LSP Tunnels, 235 [RFC3209]. 237 Constraint-Based LSP Setup using LDP, [RFC3212]." 238 SYNTAX Unsigned32(0..4294967295) 239 MplsLabel ::= TEXTUAL-CONVENTION 240 STATUS current 241 DESCRIPTION 242 "This value represents an MPLS label as defined in 243 [RFC3031], [RFC3032], [RFC3034], [RFC3035] and 244 [RFC3471]. 246 The label contents are specific to the label being 247 represented, such as: 249 * The label carried in an MPLS shim header 250 (for LDP this is the Generic Label) is a 20-bit 251 number represented by 4 octets. Bits 0-19 contain 252 a label or a reserved label value. Bits 20-31 253 MUST be zero. 255 The following is quoted directly from [RFC3032]. 256 There are several reserved label values: 258 i. A value of 0 represents the 259 'IPv4 Explicit NULL Label'. This label 260 value is only legal at the bottom of the 261 label stack. It indicates that the label 262 stack must be popped, and the forwarding 263 of the packet must then be based on the 264 IPv4 header. 266 ii. A value of 1 represents the 267 'Router Alert Label'. This label value is 268 legal anywhere in the label stack except at 269 the bottom. When a received packet 270 contains this label value at the top of 271 the label stack, it is delivered to a 272 local software module for processing. 273 The actual forwarding of the packet 274 is determined by the label beneath it 275 in the stack. However, if the packet is 276 forwarded further, the Router Alert Label 277 should be pushed back onto the label stack 278 before forwarding. The use of this label 279 is analogous to the use of the 280 'Router Alert Option' in IP packets 281 [RFC2113]. Since this label 282 cannot occur at the bottom of the stack, 283 it is not associated with a 284 particular network layer protocol. 286 iii. A value of 2 represents the 287 'IPv6 Explicit NULL Label'. This label 288 value is only legal at the bottom of the 289 label stack. It indicates that the label 290 stack must be popped, and the forwarding 291 of the packet must then be based on the 292 IPv6 header. 294 iv. A value of 3 represents the 295 'Implicit NULL Label'. 296 This is a label that an LSR may assign and 297 distribute, but which never actually 298 appears in the encapsulation. When an 299 LSR would otherwise replace the label 300 at the top of the stack with a new label, 301 but the new label is 'Implicit NULL', 302 the LSR will pop the stack instead of 303 doing the replacement. Although 304 this value may never appear in the 305 encapsulation, it needs to be specified in 306 the Label Distribution Protocol, so a value 307 is reserved. 309 v. Values 4-15 are reserved. 311 * The frame relay label can be either 10-bits or 312 23-bits depending on the DLCI field size and the 313 upper 22-bits or upper 9-bits must be zero, 314 respectively. 316 * For an ATM label the lower 16-bits represents the 317 VCI, the next 12-bits represents the VPI and the 318 remaining bits MUST be zero. 320 * The Generalized-MPLS (GMPLS) label contains a 321 value greater than 2^24-1 and used in GMPLS 322 as defined in [RFC3471]." 323 REFERENCE 324 "Multiprotocol Label Switching Architecture, 325 [RFC3031]. 327 MPLS Label Stack Encoding, [RFC3032]. 329 Use of Label Switching on Frame Relay Networks, 330 [RFC3034]. 332 MPLS using LDP and ATM VC Switching, [RFC3035]. 333 Generalized Multiprotocol Label Switching 334 (GMPLS) Architecture, [RFC3471]." 335 SYNTAX Unsigned32 (0..4294967295) 337 MplsLabelDistributionMethod ::= TEXTUAL-CONVENTION 338 STATUS current 339 DESCRIPTION 340 "The label distribution method which is also called 341 the label advertisement mode [RFC3036]. 342 Each interface on an LSR is configured to operate 343 in either Downstream Unsolicited or Downstream 344 on Demand." 345 REFERENCE 346 "Multiprotocol Label Switching Architecture, 347 [RFC3031]. 349 LDP Specification, RFC3036, Section 2.6.3." 350 SYNTAX INTEGER { 351 downstreamOnDemand(1), 352 downstreamUnsolicited(2) 353 } 355 MplsLdpIdentifier ::= TEXTUAL-CONVENTION 356 DISPLAY-HINT "1d.1d.1d.1d:2d" 357 STATUS current 358 DESCRIPTION 359 "The LDP identifier is a six octet 360 quantity which is used to identify a 361 Label Switching Router (LSR) label space. 363 The first four octets identify the LSR and 364 must be a globally unique value, such as a 365 32-bit router ID assigned to the LSR, and the 366 last two octets identify a specific label 367 space within the LSR." 368 SYNTAX OCTET STRING (SIZE (6)) 370 MplsLsrIdentifier ::= TEXTUAL-CONVENTION 371 STATUS current 372 DESCRIPTION 373 "The Label Switching Router (LSR) identifier is the 374 first 4 bytes of the Label Distribution Protocol 375 (LDP) identifier." 376 SYNTAX OCTET STRING (SIZE (4)) 377 MplsLdpLabelType ::= TEXTUAL-CONVENTION 378 STATUS current 379 DESCRIPTION 380 "The Layer 2 label types which are defined for MPLS 381 LDP and/or CR-LDP are generic(1), atm(2), or 382 frameRelay(3)." 383 SYNTAX INTEGER { 384 generic(1), 385 atm(2), 386 frameRelay(3) 387 } 389 MplsLSPID ::= TEXTUAL-CONVENTION 390 STATUS current 391 DESCRIPTION 392 "A unique identifier within an MPLS network that is 393 assigned to each LSP. This is assigned at the head 394 end of the LSP and can be used by all LSRs 395 to identify this LSP. This value is piggybacked by 396 the signaling protocol when this LSP is signaled 397 within the network. This identifier can then be 398 used at each LSR to identify which labels are 399 being swapped to other labels for this LSP. This 400 object can also be used to disambiguate LSPs that 401 share the same RSVP sessions between the same 402 source and destination. 404 For LSPs established using CR-LDP, the LSPID is 405 composed of the ingress LSR Router ID (or any of 406 its own IPv4 addresses) and a locally unique 407 CR-LSP ID to that LSR. The first two bytes carry 408 the CR-LSPID, and the remaining 4 bytes carry 409 the Router ID. The LSPID is useful in network 410 management, in CR-LSP repair, and in using 411 an already established CR-LSP as a hop in 412 an ER-TLV. 414 For LSPs signaled using RSVP-TE, the LSP ID is 415 defined as a 16-bit (2 byte) identifier used 416 in the SENDER_TEMPLATE and the FILTER_SPEC 417 that can be changed to allow a sender to 418 share resources with itself. The length of this 419 object should only be 2 or 6 bytes. If the length 420 of this octet string is 2 bytes, then it must 421 identify an RSVP-TE LSPID, or it is 6 bytes, 422 it must contain a CR-LDP LSPID." 423 REFERENCE 424 "RSVP-TE: Extensions to RSVP for LSP Tunnels, 425 [RFC3209]. 427 Constraint-Based LSP Setup using LDP, 428 [RFC3212]." 429 SYNTAX OCTET STRING (SIZE (2|6)) 430 MplsLspType ::= TEXTUAL-CONVENTION 431 STATUS current 432 DESCRIPTION 433 "Types of Label Switch Paths (LSPs) 434 on a Label Switching Router (LSR) or a 435 Label Edge Router (LER) are: 437 unknown(1) -- if the LSP is not known 438 to be one of the following. 440 terminatingLsp(2) -- if the LSP terminates 441 on the LSR/LER, then this 442 is an egressing LSP 443 which ends on the LSR/LER, 445 originatingLsp(3) -- if the LSP originates 446 from this LSR/LER, then 447 this is an ingressing LSP 448 which is the head-end of 449 the LSP, 451 crossConnectingLsp(4) -- if the LSP ingresses 452 and egresses on the LSR, then it is 453 cross-connecting on that LSR." 454 SYNTAX INTEGER { 455 unknown(1), 456 terminatingLsp(2), 457 originatingLsp(3), 458 crossConnectingLsp(4) 459 } 461 MplsOwner ::= TEXTUAL-CONVENTION 462 STATUS current 463 DESCRIPTION 464 "This object indicates the local network 465 management subsystem that originally created 466 the object(s) in question. The values of 467 this enumeration are defined as follows: 469 unknown(1) - the local network management 470 subsystem cannot discern which 471 component created the object. 473 other(2) - the local network management 474 subsystem is able to discern which component 475 created the object, but the component is not 476 listed within the following choices, 477 e.g., command line interface (cli). 479 snmp(3) - The Simple Network Management Protocol 480 was used to configure this object initially. 482 ldp(4) - The Label Distribution Protocol was 483 used to configure this object initially. 485 crldp(5) - The Constraint-Based Label Distribution 486 Protocol was used to configure this object 487 initially. 489 rsvpTe(6) - The Resource Reservation Protocol was 490 used to configure this object initially. 492 policyAgent(7) - A policy agent (perhaps in 493 combination with one of the above protocols) was 494 used to configure this object initially. 496 An object created by any of the above choices 497 MAY be modified or destroyed by the same or a 498 different choice." 499 SYNTAX INTEGER { 500 unknown(1), 501 other(2), 502 snmp(3), 503 ldp(4), 504 crldp(5), 505 rsvpTe(6), 506 policyAgent(7) 507 } 509 MplsPathIndexOrZero ::= TEXTUAL-CONVENTION 510 STATUS current 511 DESCRIPTION 512 "A unique identifier used to identify a specific 513 path used by a tunnel. A value of 0 (zero) means 514 that no path is in use." 515 SYNTAX Unsigned32(0..4294967295) 517 MplsPathIndex ::= TEXTUAL-CONVENTION 518 STATUS current 519 DESCRIPTION 520 "A unique value to index (by Path number) an 521 entry in a table." 522 SYNTAX Unsigned32(1..4294967295) 524 MplsRetentionMode ::= TEXTUAL-CONVENTION 525 STATUS current 526 DESCRIPTION 527 "The label retention mode which specifies whether 528 an LSR maintains a label binding for a FEC 529 learned from a neighbor that is not its next hop 530 for the FEC. 532 If the value is conservative(1) then advertised 533 label mappings are retained only if they will be 534 used to forward packets, i.e., if label came from 535 a valid next hop. 537 If the value is liberal(2) then all advertised 538 label mappings are retained whether they are from 539 a valid next hop or not." 540 REFERENCE 541 "Multiprotocol Label Switching Architecture, 542 [RFC3031]. 544 LDP Specification, [RFC3036], Section 2.6.2." 545 SYNTAX INTEGER { 546 conservative(1), 547 liberal(2) 548 } 550 MplsTunnelAffinity ::= TEXTUAL-CONVENTION 551 STATUS current 552 DESCRIPTION 553 "Describes the configured 32-bit Include-any, 554 include-all, or exclude-all constraint for 555 constraint-based link selection." 556 REFERENCE 557 "RSVP-TE: Extensions to RSVP for LSP Tunnels, 558 [RFC3209], Section 4.7.4." 559 SYNTAX Unsigned32(0..4294967295) 561 MplsTunnelIndex ::= TEXTUAL-CONVENTION 562 STATUS current 563 DESCRIPTION 564 "A unique index into mplsTunnelTable. 565 For tunnels signaled using RSVP, this value 566 should correspond to the RSVP Tunnel ID 567 used for the RSVP-TE session." 568 SYNTAX Unsigned32 (0..65535) 570 MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION 571 STATUS current 572 DESCRIPTION 573 "The tunnel entry with instance index 0 574 should refer to the configured tunnel 575 interface (if one exists). 577 Values greater than 0, but less than or 578 equal to 65535, should be used to indicate 579 signaled (or backup) tunnel LSP instances. 580 For tunnel LSPs signaled using RSVP, 581 this value should correspond to the 582 RSVP LSP ID used for the RSVP-TE 583 LSP. 585 Values greater than 65535 apply to FRR 586 detour instances." 587 SYNTAX Unsigned32(0|1..65535|65536..4294967295) 589 TeHopAddressType ::= TEXTUAL-CONVENTION 590 STATUS current 591 DESCRIPTION 592 "A value that represents a type of address for a 593 Traffic Engineered (TE) Tunnel hop. 595 unknown(0) An unknown address type. This value 596 MUST be used if the value of the 597 corresponding TeHopAddress object is a 598 zero-length string. It may also be 599 used to indicate a TeHopAddress which 600 is not in one of the formats defined 601 below. 603 ipv4(1) An IPv4 network address as defined by 604 the InetAddressIPv4 TEXTUAL-CONVENTION 605 [RFC3291]. 607 ipv6(2) A global IPv6 address as defined by 608 the InetAddressIPv6 TEXTUAL-CONVENTION 609 [RFC3291]. 611 asnumber(3) An Autonomous System (AS) number as 612 defined by the TeHopAddressAS 613 TEXTUAL-CONVENTION. 615 unnum(4) An unnumbered interface index as 616 defined by the TeHopAddressUnnum 617 TEXTUAL-CONVENTION. 619 lspid(5) An LSP ID for TE Tunnels 620 (RFC3212) as defined by the 621 MplsLSPID TEXTUAL-CONVENTION. 623 Each definition of a concrete TeHopAddressType 624 value must be accompanied by a definition 625 of a TEXTUAL-CONVENTION for use with that 626 TeHopAddress. 628 To support future extensions, the TeHopAddressType 629 TEXTUAL-CONVENTION SHOULD NOT be sub-typed in 630 object type definitions. It MAY be sub-typed in 631 compliance statements in order to require only a 632 subset of these address types for a compliant 633 implementation. 635 Implementations must ensure that TeHopAddressType 636 objects and any dependent objects 637 (e.g., TeHopAddress objects) are consistent. 638 An inconsistentValue error must be generated 639 if an attempt to change a TeHopAddressType 640 object would, for example, lead to an 641 undefined TeHopAddress value that is 642 not defined herein. In particular, 643 TeHopAddressType/TeHopAddress pairs 644 must be changed together if the address 645 type changes (e.g., from ipv6(2) to ipv4(1))." 646 REFERENCE 647 "TEXTUAL-CONVENTIONs for Internet Network 648 Addresses, [RFC3291]. 650 Constraint-Based LSP Setup using LDP, 651 [RFC3212]" 653 SYNTAX INTEGER { 654 unknown(0), 655 ipv4(1), 656 ipv6(2), 657 asnumber(3), 658 unnum(4), 659 lspid(5) 660 } 662 TeHopAddress ::= TEXTUAL-CONVENTION 663 STATUS current 664 DESCRIPTION 665 "Denotes a generic Tunnel hop address, 666 that is, the address of a node which 667 an LSP traverses, including the source 668 and destination nodes. An address may be 669 very concrete, for example, an IPv4 host 670 address (i.e., with prefix length 32); 671 if this IPv4 address is an interface 672 address, then that particular interface 673 must be traversed. An address may also 674 specify an 'abstract node', for example, 675 an IPv4 address with prefix length 676 less than 32, in which case, the LSP 677 can traverse any node whose address 678 falls in that range. An address may 679 also specify an Autonomous System (AS), 680 in which case the LSP can traverse any 681 node that falls within that AS. 683 A TeHopAddress value is always interpreted within 684 the context of an TeHopAddressType value. Every 685 usage of the TeHopAddress TEXTUAL-CONVENTION 686 is required to specify the TeHopAddressType object 687 which provides the context. It is suggested that 688 the TeHopAddressType object is logically registered 689 before the object(s) which use the TeHopAddress 690 TEXTUAL-CONVENTION if they appear in the 691 same logical row. 693 The value of a TeHopAddress object must always be 694 consistent with the value of the associated 695 TeHopAddressType object. Attempts to set a 696 TeHopAddress object to a value which is 697 inconsistent with the associated TeHopAddressType 698 must fail with an inconsistentValue error." 699 SYNTAX OCTET STRING (SIZE (0..32)) 701 TeHopAddressAS ::= TEXTUAL-CONVENTION 702 STATUS current 703 DESCRIPTION 704 "Represents a two or four octet AS number. 705 The AS number is represented in network byte 706 order (MSB first). A two-octet AS number has 707 the two MSB octets set to zero." 708 REFERENCE 709 "Textual Conventions for Internet Network 710 Addresses, [RFC3291]. The 711 InetAutonomousSystemsNumber TEXTUAL-CONVENTION 712 has a SYNTAX of Unsigned32, whereas this TC 713 has a SYNTAX of OCTET STRING (SIZE (4)). 714 Both TCs represent an autonomous system number 715 but use different syntaxes to do so." 716 SYNTAX OCTET STRING (SIZE (4)) 717 TeHopAddressUnnum ::= TEXTUAL-CONVENTION 718 STATUS current 719 DESCRIPTION 720 "Represents an unnumbered interface: 722 octets contents encoding 723 1-4 unnumbered interface network-byte order 725 The corresponding TeHopAddressType value is 726 unnum(5)." 727 SYNTAX OCTET STRING(SIZE(4)) 729 MplsNewExtendedTunnelId ::= TEXTUAL-CONVENTION 730 STATUS current 731 DESCRIPTION 732 "A unique identifier for an MPLS Tunnel. This may 733 represent an IPv4 address of the ingress or egress 734 LSR for the tunnel for an IPv4 network. For IPv6 735 this represents an IPv4 address of the ingress or 736 egress LSR for the tunnel for an IPv6 network. 737 This value is derived from the 738 Extended Tunnel Id in RSVP or the Ingress Router ID 739 for CR-LDP." 740 REFERENCE 741 "RSVP-TE: Extensions to RSVP for LSP Tunnels, 742 [RFC3209]. 744 Constraint-Based LSP Setup using LDP, [RFC3212]." 745 SYNTAX OCTET STRING(SIZE(16)) 746 END 748 4. Changes from RFC3811 750 Following is the list of technical changes and other fixes from 751 RFC3811. 753 Main purpose of this work is to address the need to support IPv6 754 extended TunnelID's by defining a new TC-MplsNewExtendedTunnelID, 755 resulting in the following changes: 757 Old MplsExtendedTunnelId status is changed to obsolete. 759 A new defined MplsNewExtendedTunnelId is added as below. 761 MplsNewExtendedTunnelId ::= TEXTUAL-CONVENTION 762 STATUS current 763 DESCRIPTION 764 "A unique identifier for an MPLS Tunnel. This may 765 represent an IPv4 address of the ingress or egress 766 LSR for the tunnel for an IPv4 network. For IPv6 767 this represents an IPv4 address of the ingress or 768 egress LSR for the tunnel for an IPv6 network. 769 This value is derived from the 770 Extended Tunnel Id in RSVP or the Ingress Router ID 771 for CR-LDP." 772 REFERENCE 773 "RSVP-TE: Extensions to RSVP for LSP Tunnels, 774 [RFC3209]. 776 Constraint-Based LSP Setup using LDP, [RFC3212]." 777 SYNTAX OCTET STRING(SIZE(16)) 779 5. Effect of the new TC 781 The new TC definition for the MPLS Tunnel will have an effect on the 782 MPLS-TE-MIB and MPLS-TC-STD-MIB. Also the following RFCs which use 783 the MIB may have to be updated to accommodate the changed definition: 784 [RFC3209], [RFC3812], [RFC3813], [RFC3212], [RFC4368], [RFC3814], 785 [RFC3815], and [RFC6639]. 787 6. Contributors 789 This MIB fixes a small issue with the earlier version of this MIB as 790 defined in RFC3811.The earlier document was created by combining 791 TEXTUAL-CONVENTIONS from current MPLS MIBs and a TE-WG MIB. Co- 792 authors on each of these MIBs contributed to the TEXTUAL-CONVENTIONS 793 contained in this MIB and also contributed greatly to the revisions 794 of this document. These co-authors are: 796 Rajiv Papneja 797 Huawei Technologies 798 2330 Central Expressway 799 Santa Clara, CA 95050 800 USA 802 Email: rajiv.papneja@huawei.com 804 Cheenu Srinivasan 805 Bloomberg L.P. 806 499 Park Ave. 807 New York, NY 10022 809 Phone: +1-212-893-3682 810 EMail: cheenu@bloomberg.net 812 Arun Viswanathan 813 Force10 Networks, Inc. 814 1440 McCarthy Blvd 815 Milpitas, CA 95035 817 Phone: +1-408-571-3516 818 EMail: arunv@force10networks.com 820 Hans Sjostrand 821 ipUnplugged 822 P.O. Box 101 60 823 S-121 28 Stockholm, Sweden 825 Phone: +46-8-725-5900 826 EMail: hans@ipunplugged.com 828 Kireeti Kompella 829 Juniper Networks 830 1194 Mathilda Ave 831 Sunnyvale, CA 94089 833 Phone: +1-408-745-2000 834 EMail: kireeti@juniper.net 836 Thomas D. Nadeau 837 Cisco Systems, Inc. 838 BXB300/2/ 839 300 Beaver Brook Road 840 Boxborough, MA 01719 842 Phone: +1-978-936-1470 843 EMail: tnadeau@cisco.com 845 Joan E. Cucchiara 846 Marconi Communications, Inc. 847 900 Chelmsford Street 848 Lowell, MA 01851 850 Phone: +1-978-275-7400 851 EMail: jcucchiara@mindspring.com 853 7. Acknowledgements 855 The author would like to thank Adrian Farrel and Thomas Nadeau for 856 thier guidance. The earlier editors and contributors would like to 857 thank Mike MacFadden and Adrian Farrel for their helpful comments on 858 several reviews. Also, a special acknowledgement to Bert Wijnen for 859 his many detailed reviews. Bert's assistance and guidance is greatly 860 appreciated. 862 8. Security Considerations 864 This module does not define any management objects. Instead, it 865 defines a set of textual conventions which may be used by other MPLS 866 MIB modules to define management objects. 868 Meaningful security considerations can only be written in the MIB 869 modules that define management objects. Therefore, this document has 870 no impact on the security of the Internet. 872 9. IANA Considerations 874 IANA has made a MIB OID assignment under the transmission branch, 875 that is, assigned the mplsStdMIB under { transmission 166 }. This 876 sub-id is requested because 166 is the ifType for mpls(166) and is 877 available under transmission. 879 In the future, MPLS related standards track MIB modules should be 880 rooted under the mplsStdMIB subtree. The IANA is requested to manage 881 that namespace. New assignments can only be made via a Standards 882 Action as specified in [RFC2434]. 884 The IANA has also assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB 885 specified in this document. 887 10. References 889 10.1. Normative References 891 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 892 1997. 894 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 895 Requirement Levels", BCP 14, RFC 2119, March 1997. 897 [RFC2434] Narten, T. and H.T. Alvestrand, "Guidelines for Writing an 898 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 899 October 1998. 901 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 902 Schoenwaelder, Ed., "Structure of Management Information 903 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 905 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 906 Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 907 58, RFC 2579, April 1999. 909 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 910 "Conformance Statements for SMIv2", STD 58, RFC 2580, 911 April 1999. 913 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 914 Label Switching Architecture", RFC 3031, January 2001. 916 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 917 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 918 Encoding", RFC 3032, January 2001. 920 [RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label 921 Switching on Frame Relay Networks Specification", RFC 922 3034, January 2001. 924 [RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., 925 Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP 926 and ATM VC Switching", RFC 3035, January 2001. 928 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 929 B. Thomas, "LDP Specification", RFC 3036, January 2001. 931 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 932 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 933 Tunnels", RFC 3209, December 2001. 935 [RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, 936 L., Doolan, P., Worster, T., Feldman, N., Fredette, A., 937 Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. 938 Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, 939 January 2002. 941 [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. 942 Schoenwaelder, "Textual Conventions for Internet Network 943 Addresses", RFC 3291, May 2002. 945 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 946 (GMPLS) Signaling Functional Description", RFC 3471, 947 January 2003. 949 10.2. Informative References 951 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 952 "Introduction and Applicability Statements for Internet- 953 Standard Management Framework", RFC 3410, December 2002. 955 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 956 "Multiprotocol Label Switching (MPLS) Traffic Engineering 957 (TE) Management Information Base (MIB)", RFC 3812, June 958 2004. 960 [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, 961 "Multiprotocol Label Switching (MPLS) Label Switching 962 Router (LSR) Management Information Base (MIB)", RFC 3813, 963 June 2004. 965 [RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan, 966 "Multiprotocol Label Switching (MPLS) Forwarding 967 Equivalence Class To Next Hop Label Forwarding Entry (FEC- 968 To-NHLFE) Management Information Base (MIB)", RFC 3814, 969 June 2004. 971 [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions 972 of Managed Objects for the Multiprotocol Label Switching 973 (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 974 2004. 976 [RFC4368] Nadeau, T. and S. Hegde, "Multiprotocol Label Switching 977 (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) 978 and Frame-Relay Management Interface Definition", RFC 979 4368, January 2006. 981 [RFC6639] King, D. and M. Venkatesan, "Multiprotocol Label Switching 982 Transport Profile (MPLS-TP) MIB-Based Management 983 Overview", RFC 6639, June 2012. 985 Authors' Addresses 987 Vishwas Manral 988 Hewlett-Packard Corp. 989 191111 Pruneridge Ave. 990 Cupertino, CA 95015 991 USA 993 Phone: +1-408-447-1497 994 Email: vishwas.manral@hp.com 995 Tina Tsou 996 Huawei Technologies (USA) 997 2330 Central Expressway 998 Santa Clara, CA 95050 999 USA 1001 Phone: +1 408 330 4424 1002 Email: tina.tsou.zouting@huawei.com 1004 Will (Shucheng) Liu 1005 Huawei Technologies 1006 Bantian, Longgang District 1007 Shenzhen 518129 1008 P.R. China 1010 Email: liushucheng@huawei.com