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