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