smilint output for ./MPLS-TC-MIB

Messages:

MPLS-TC-MIB

   1: -- extracted from draft-ietf-mpls-tc-mib-06.txt
   2: -- at Thu Apr  3 06:12:42 2003

   3: 
   4:      MPLS-TC-MIB DEFINITIONS ::= BEGIN
   5: 
   6:           IMPORTS
   7: 
   8:              MODULE-IDENTITY, Unsigned32, Integer32, transmission
   9:                 FROM SNMPv2-SMI
  10: 
  11:              TEXTUAL-CONVENTION
  12:                 FROM SNMPv2-TC;
  13: 
  14:           mplsTCMIB MODULE-IDENTITY
  15:              LAST-UPDATED "200303171200Z" -- 17 March 2003 12:00:00 GMT
  16:              ORGANIZATION
  17:                   "IETF Multiprotocol Label Switching (MPLS) Working
  18:                    Group."
  19:              CONTACT-INFO
  20:                   "        Thomas D. Nadeau
  21:                            Cisco Systems, Inc.
  22:                            tnadeau@cisco.com
  23: 
  24:                            Joan Cucchiara
  25:                            Artel
  26:                            jcucchiara@artel.com
  27: 
  28:                            Cheenu Srinivasan
  29:                            Parama Networks, Inc.
  30:                            cheenu@paramanet.com
  31: 
  32:                            Arun Viswanathan
  33:                            Force10 Networks, Inc.
  34:                            arun@force10networks.com
  35: 
  36:                            Hans Sjostrand
  37:                            ipUnplugged
  38:                            hans@ipunplugged.com
  39: 
  40:                            Kireeti Kompella
  41:                            Juniper Networks
  42:                            kireeti@juniper.net
  43: 
  44: 
  45:                   Email comments to the MPLS WG Mailing List at
  46:                   mpls@uu.net."
  47:              DESCRIPTION
  48:                   "Copyright (C) The Internet Society (2003).  This
  49:                    version of this MIB module is part of RFCXXX; see
  50:                    the RFC itself for full legal notices.
  51: 
  52:                    This MIB module defines Textual Conventions
  53:                    for concepts used in Multi-Protocol Label
  54:                    Switching (MPLS) networks."
  55: 
  56:              REVISION "200303171200Z" -- 17 March 2003 12:00:00 GMT
  57:              DESCRIPTION
  58:                   "Initial version published as part of RFC XXXX."
  59:              ::= { mplsMIB 1 }

  60: 
  61:           -- This object identifier needs to be assigned by IANA.
  62:           -- Since mpls has been assigned an ifType of 166 we recommend
  63:           -- that this OID be 166 as well.
  64:           mplsMIB OBJECT IDENTIFIER
  65:              ::= { transmission XXX }

  66: 
  67: 
  68:           MplsAtmVcIdentifier ::= TEXTUAL-CONVENTION

  69:              DISPLAY-HINT "d"
  70:              STATUS  current
  71:              DESCRIPTION
  72:                   "A Label Switching Router (LSR) that
  73:                    creates LDP sessions on ATM interfaces
  74:                    uses the VCI or VPI/VCI field to hold the
  75:                    LDP Label.
  76: 
  77:                    VCI values MUST NOT be in the 0-31 range.
  78:                    The values 0 to 31 are reserved for other uses
  79:                    by the ITU and ATM Forum.  The value
  80:                    of 32 can only be used for the Control VC,
  81:                    although values greater than 32 could be
  82:                    configured for the Control VC.
  83: 
  84:                    If a value from 0 to 31 is used for a VCI
  85:                    the management entity controlling the LDP
  86:                    subsystem should reject this with an
  87:                    inconsistentValue error.  Also, if
  88:                    the value of 32 is used for a VC which is
  89:                    NOT the Control VC, this should
  90:                    result in an inconsistentValue error."
  91:              REFERENCE
  92:                   "MPLS using LDP and ATM VC Switching, RFC3035."
  93:              SYNTAX  Integer32 (32..65535)
  94: 
  95:           MplsBitRate ::= TEXTUAL-CONVENTION

  96:              DISPLAY-HINT "d"
  97:              STATUS      current
  98:              DESCRIPTION
  99:                   "If the value of this object is greater than zero,
 100:                    then this represents the bandwidth of this MPLS
 101:                    interface (or Label Switched Path) in units of
 102:                    '1,000 bits per second'.
 103: 
 104:                    The value, when greater than zero, represents the
 105:                    bandwidth of this MPLS interface (rounded to the
 106:                    nearest 1,000) in units of 1,000 bits per second.
 107:                    If the bandwidth of the MPLS interface is between
 108:                    ((n * 1000) - 500) and ((n * 1000) + 499), the value
 109:                    of this object is n, such that n > 0.
 110:                    If the value of this object is 0 (zero), this
 111:                    means that the traffic over this MPLS interface is
 112:                    considered to be best effort."
 113:              SYNTAX  Unsigned32 (0|1..4294967295)
 114: 
 115:           MplsBurstSize ::= TEXTUAL-CONVENTION

 116:              DISPLAY-HINT "d"
 117:              STATUS      current
 118:              DESCRIPTION
 119:                   "The number of octets of MPLS data that the stream
 120:                    may send back-to-back without concern for policing.
 121:                    The value of zero indicates that an implementation
 122:                    does not support Burst Size."
 123:              SYNTAX  Unsigned32 (0..4294967295)
 124: 
 125:           MplsExtendedTunnelId ::= TEXTUAL-CONVENTION

 126:              STATUS        current
 127:              DESCRIPTION
 128:                   "A unique identifier for an MPLS Tunnel. This may
 129:                    represent an IPv4 address of the ingress or egress
 130:                    LSR for the tunnel. This value is derived from the
 131:                    Extended Tunnel Id in RSVP or the Ingress Router ID
 132:                    for CR-LDP."
 133:              REFERENCE
 134:                   "RSVP-TE: Extensions to RSVP for LSP Tunnels,  RFC 3209.
 135: 
 136:                    Constraint-Based LSP Setup using LDP, RFC 3212."
 137:              SYNTAX  Unsigned32
 138: 
 139: 
 140:           MplsLabel ::= TEXTUAL-CONVENTION

 141:              STATUS        current
 142:              DESCRIPTION
 143:                   "This value represents an MPLS label as defined in
 144:                    (RFC3031),  (RFC3032), (RFC3034), (RFC3035) and
 145:                    (CCAMP-ARCH).
 146: 
 147:                    The label contents are specific to the label being
 148:                    represented, such as:
 149: 
 150:                    * The label carried in an MPLS shim header
 151:                      (for LDP this is the Generic Label) is a 20-bit
 152:                      number represented by 4 octets. Bits 0-19 contain
 153:                      a label or a reserved label value.  Bits 20-31
 154:                      MUST be zero.
 155:                      The following is quoted directly from [RFC3032].
 156:                      There are several reserved label values:
 157: 
 158:                         i. A value of 0 represents the
 159:                            'IPv4 Explicit NULL Label'. This label
 160:                            value is only legal at the bottom of the
 161:                            label stack.  It indicates that the label
 162:                            stack must be popped, and the forwarding
 163:                            of the packet must then be based on the
 164:                            IPv4 header.
 165: 
 166:                        ii. A value of 1 represents the
 167:                            'Router Alert Label'.  This label value is
 168:                            legal anywhere in the label stack except at
 169:                            the bottom.  When a received packet
 170:                            contains this label value at the top of
 171:                            the label stack, it is delivered to a
 172:                            local software module for processing.
 173:                            The actual forwarding of the packet
 174:                            is determined by the label beneath it
 175:                            in the stack.  However, if the packet is
 176:                            forwarded further, the Router Alert Label
 177:                            should be pushed back onto the label stack
 178:                            before forwarding.  The use of this label
 179:                            is analogous to the use of the
 180:                            'Router Alert Option' in IP packets [5]
 181:                            [Reference to RFC2113]. Since this label
 182:                            cannot occur at the bottom of the stack,
 183:                            it is not associated with a
 184:                            particular network layer protocol.
 185: 
 186:                       iii. A value of 2 represents the
 187:                            'IPv6 Explicit NULL Label'. This label
 188:                            value is only legal at the bottom of the
 189:                            label stack.  It indicates that the label
 190:                            stack must be popped, and the forwarding
 191:                            of the packet must then be based on the
 192:                            IPv6 header.
 193: 
 194:                        iv. A value of 3 represents the
 195:                            'Implicit NULL Label'.
 196:                            This is a label that an LSR may assign and
 197:                            distribute, but which never actually
 198:                            appears in the encapsulation.  When an
 199:                            LSR would otherwise replace the label
 200:                            at the top of the stack with a new label,
 201:                            but the new label is 'Implicit NULL',
 202:                            the LSR will pop the stack instead of
 203:                            doing the replacement.  Although
 204:                            this value may never appear in the
 205:                            encapsulation, it needs to be specified in
 206:                            the Label Distribution Protocol, so a value
 207:                            is reserved.
 208: 
 209:                         v. Values 4-15 are reserved.
 210: 
 211:                    * The frame relay label can be either 10-bits or
 212:                      23-bits depending on the DLCI field size and the
 213:                      upper 22-bits or upper 9-bits must be zero,
 214:                      respectively.
 215: 
 216:                    * For an ATM label the lower 16-bits represents the
 217:                      VCI, the next 12-bits represents the VPI and the
 218:                      remaining bits MUST be zero.
 219: 
 220:                    * The Generalized-MPLS (GMPLS) label contains a
 221:                      value greater than 2^24-1 and used in GMPLS
 222:                      as defined in [CCAMP-ARCH]."
 223: 
 224:              REFERENCE
 225:                   "Multiprotocol Label Switching Architecture,
 226:                    RFC 3031.
 227: 
 228:                    MPLS Label Stack Encoding, RFC 3032.
 229: 
 230:                    Use of Label Switching on Frame Relay Networks,
 231:                    RFC 3034.
 232: 
 233:                    MPLS using LDP and ATM VC Switching, RFC 3035.
 234: 
 235:                    Generalized Multi-Protocol Label Switching
 236:                    (GMPLS) Architecture,
 237:                    draft-ietf-ccamp-gmpls-architecture-02.txt."
 238:              SYNTAX  Unsigned32 (0..4294967295)
 239: 
 240:           MplsLabelDistributionMethod ::= TEXTUAL-CONVENTION

 241:              STATUS  current
 242:              DESCRIPTION
 243:                   "The label distribution method which is also called
 244:                    the label advertisement mode (see LDP Specification).
 245:                    Each interface on an LSR is configured to operate
 246:                    in either Downstream Unsolicited or Downstream
 247:                    on Demand."
 248:              REFERENCE
 249:                   "Multiprotocol Label Switching Architecture,
 250:                    RFC 3031.
 251: 
 252:                    LDP Specification, RFC 3036, Section 2.6.3."
 253:              SYNTAX INTEGER {
 254:                         downstreamOnDemand(1),
 255:                         downstreamUnsolicited(2)
 256:                     }
 257: 
 258:           MplsLdpIdentifier ::= TEXTUAL-CONVENTION

 259:              DISPLAY-HINT "1d.1d.1d.1d:2d"
 260:              STATUS      current
 261:              DESCRIPTION
 262:                   "The LDP identifier is a six octet
 263:                    quantity which is used to identify a
 264:                    Label Switching Router (LSR) label space.
 265: 
 266:                    The first four octets identify the LSR and must be
 267:                    a globally unique value, such as a 32-bit router ID
 268:                    assigned to the LSR, and the last two octets
 269:                    identify a specific label space within the LSR."
 270:              SYNTAX  OCTET STRING (SIZE (6))
 271: 
 272:           MplsLsrIdentifier ::= TEXTUAL-CONVENTION

 273:              STATUS      current
 274:              DESCRIPTION
 275:                   "The Label Switching Router (LSR) identifier is the
 276:                    first 4 bytes of the Label Distribution Protocol
 277:                    (LDP) identifier."
 278:              SYNTAX  OCTET STRING (SIZE (4))
 279: 
 280:           MplsLdpLabelType ::= TEXTUAL-CONVENTION

 281:              STATUS      current
 282:              DESCRIPTION
 283:                   "The Layer 2 label types which are defined for MPLS
 284:                    LDP and/or CR-LDP are generic(1), atm(2), or
 285:                    frameRelay(3)."
 286:              SYNTAX  INTEGER {
 287:                        generic(1),
 288:                        atm(2),
 289:                        frameRelay(3)
 290:                    }
 291: 
 292:           MplsLSPID ::= TEXTUAL-CONVENTION

 293:              STATUS        current
 294:              DESCRIPTION
 295:                   "A unique identifier within an MPLS network that is
 296:                    assigned to each LSP. This is assigned at the head
 297:                    end of the LSP and can be used by all LSRs
 298:                    to identify this LSP.  This value is piggybacked by
 299:                    the signaling protocol when this LSP is signaled
 300:                    within the network. This identifier can then be
 301:                    used at each LSR to identify which labels are being
 302:                    swapped to other labels for this LSP. This object
 303:                    can also be used to disambiguate LSPs that
 304:                    share the same RSVP sessions between the same
 305:                    source and destination.
 306: 
 307:                    For LSPs established using CR-LDP, the LSPID is
 308:                    composed of the ingress LSR Router ID (or any of
 309:                    its own IPv4 addresses) and a locally unique
 310:                    CR-LSP ID to that LSR. The first two bytes carry
 311:                    the CR-LSPID, and the remaining 4 bytes carry
 312:                    the Router ID. The LSPID is useful in network
 313:                    management, in CR-LSP repair, and in using
 314:                    an already established CR-LSP as a hop in an ER-TLV.
 315: 
 316:                    For LSPs signaled using RSVP-TE, the LSP ID is
 317:                    defined as a 16-bit (2 byte) identifier used
 318:                    in the SENDER_TEMPLATE and the FILTER_SPEC
 319:                    that can be changed to allow a sender to
 320:                    share resources with itself. The length of this
 321:                    object should only be 2 or 6 bytes. If the length
 322:                    of this octet string is 2 bytes, then it must
 323:                    identify an RSVP-TE LSPID, or it is 6 bytes,
 324:                    it must contain a CR-LDP LSPID."
 325:              REFERENCE
 326:                   "RSVP-TE:  Extensions to RSVP for LSP Tunnels,
 327:                    RFC 3209.
 328: 
 329:                    Constraint-Based LSP Setup using LDP, RFC 3212."
 330:              SYNTAX  OCTET STRING (SIZE (2|6))
 331: 
 332:           MplsLspType ::= TEXTUAL-CONVENTION

 333:              STATUS  current
 334:              DESCRIPTION
 335:                   "Types types of Label Switch Paths (LSPs)
 336:                    on an Label Switching Router (LSR) ir a
 337:                    Label Edge Router (LER) are:
 338:                       unknown(1)         -- if the LSP is not known
 339:                                             to be one of the following.
 340: 
 341:                       terminatingLsp(2)  -- if the LSP terminates
 342:                                             on the LSR/LER, then this
 343:                                             is an egressing LSP
 344:                                             which ends on the LSR/LER,
 345: 
 346:                       originatingLsp(3)  -- if the LSP originates
 347:                                             from this LSR/LER, then this
 348:                                             is an ingressing LSP which is
 349:                                             the head-end of the LSP,
 350: 
 351:                    crossConnectingLsp(4) -- if the LSP ingresses
 352:                                             and egresses on the LSR,
 353:                                             then it is cross-connecting
 354:                                             on that LSR."
 355:              SYNTAX INTEGER {
 356:                         unknown(1),
 357:                         terminatingLsp(2),
 358:                         originatingLsp(3),
 359:                         crossConnectingLsp(4)
 360:                     }
 361: 
 362: 
 363:           MplsOwner ::= TEXTUAL-CONVENTION

 364:              STATUS      current
 365:              DESCRIPTION
 366:                   "This object indicates the local network management
 367:                    subsystem that originally created the object(s) in
 368:                    question. The values of this enumeration are
 369:                    defined as follows:
 370: 
 371:                    unknown(1) - the local network management
 372:                    subsystem cannot discern which
 373:                    component created the object.
 374: 
 375:                    other(2) - the local network management
 376:                    subsystem is able to discern which component
 377:                    created the object, but the component is not
 378:                    listed within the following choices,
 379:                    e.g. command line interface (cli).
 380: 
 381:                    snmp(3) - The Simple Network Management Protocol was
 382:                    used to configure this object initially.
 383:                    ldp(4) - The Label Distribution Protocol was used to
 384:                    configure this object initially.
 385: 
 386:                    crldp(5) - The Constraint-Based Label Distribution
 387:                    Protocol was used to configure this object
 388:                    initially.
 389: 
 390:                    rsvpTe(6) - The Resource Reservation Protocol was used
 391:                    to configure this object initially.
 392: 
 393:                    policyAgent(7) - A policy agent (perhaps in
 394:                    combination with one of the above protocols) was
 395:                    used to configure this object initially.
 396: 
 397:                    An object created by any of the above choices
 398:                    MAY be modified or destroyed by the same or a
 399:                    different choice."
 400:              SYNTAX  INTEGER {
 401:                        unknown(1),
 402:                        other(2),
 403:                        snmp(3),
 404:                        ldp(4),
 405:                        crldp(5),
 406:                        rsvpTe(6),
 407:                        policyAgent(7)
 408:                    }
 409: 
 410:           MplsPathIndexOrZero ::= TEXTUAL-CONVENTION

 411:              STATUS current
 412:              DESCRIPTION
 413:                   "A unique identifier used to identify a specific path
 414:                    used by a tunnel. A value of 0 (zero) means that
 415:                    no path is in use."
 416:              SYNTAX  Unsigned32
 417: 
 418:           MplsPathIndex ::= TEXTUAL-CONVENTION

 419:              STATUS        current
 420:              DESCRIPTION
 421:                   "A unique value to index (by Path number) an entry
 422:                    in a table."
 423:              SYNTAX  Unsigned32(1..4294967295)
 424: 
 425: 
 426:           MplsRetentionMode ::= TEXTUAL-CONVENTION

 427:              STATUS  current
 428:              DESCRIPTION
 429:                   "The label retention mode which specifies whether
 430:                    an LSR maintains a label binding for a FEC learned
 431:                    from a neighbor that is not its next hop for the
 432:                    FEC.
 433: 
 434:                    If the value is conservative(1) then advertised
 435:                    label mappings are retained only if they will be
 436:                    used to forward packets, i.e. if label came from
 437:                    a valid next hop.
 438: 
 439:                    If the value is liberal(2) then all advertised label
 440:                    mappings are retained whether they are from a
 441:                    valid next hop or not."
 442:              REFERENCE
 443:                   "Multiprotocol Label Switching Architecture,
 444:                    RFC 3031.
 445: 
 446:                    LDP Specification, RFC 3036, Section 2.6.2."
 447:              SYNTAX INTEGER {
 448:                         conservative(1),
 449:                         liberal(2)
 450:                     }
 451: 
 452: 
 453:           MplsTunnelAffinity ::= TEXTUAL-CONVENTION

 454:              STATUS        current
 455:              DESCRIPTION
 456:                   "Describes the configured 32-bit Include-any,
 457:                    include-all, or exclude-all constraint for
 458:                    constraint-based link selection."
 459:              REFERENCE
 460:                   "RSVP-TE:  Extensions to RSVP for LSP Tunnels,
 461:                    RFC 3209, Section 4.7.4."
 462:              SYNTAX  Unsigned32
 463: 
 464:           MplsTunnelIndex ::= TEXTUAL-CONVENTION

 465:              STATUS        current
 466:              DESCRIPTION
 467:                   "A unique index into mplsTunnelTable.
 468:                    For tunnels signaled using RSVP, this value
 469:                    should correspond to the RSVP destination
 470:                    port used for the RSVP-TE session."
 471:              SYNTAX  Unsigned32 (0..65535)
 472: 
 473:           MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION

 474:              STATUS        current
 475:              DESCRIPTION
 476:                   "Instance index into mplsTunnelTable. The
 477:                    tunnel entry with instance index 0 should
 478:                    refer to the configured tunnel interface
 479:                    (if one exists), and values greater an 0 but
 480:                    less than or equal to 65535
 481:                    should be used to indicate signaled (or backup)
 482:                    tunnel LSP instances. For tunnel LSPs signaled using
 483:                    RSVP, this value should correspond to the
 484:                    RSVP source port used for the RSVP-TE session.
 485: 
 486:                    Values greater than 65535 apply to FRR detour
 487:                    instances."
 488:              SYNTAX  Unsigned32
 489: 
 490: 
 491:           TeHopAddressType ::= TEXTUAL-CONVENTION

 492:              STATUS     current
 493:              DESCRIPTION
 494:                   "A value that represents a type of address a Traffic
 495:                    Engineered (TE) Tunnel hop.
 496: 
 497:                    unknown(0)   An unknown address type.  This value
 498:                                 MUST be used if the value of the
 499:                                 corresponding TeHopAddress object is a
 500:                                 zero-length string.  It may also be used
 501:                                 to indicate a TeHopAddress which is not
 502:                                 in one of the formats defined below.
 503: 
 504:                    ipv4(1)      An IPv4 network address as defined by
 505:                                 the InetAddressIPv4 TEXTUAL-CONVENTION
 506:                                 (RFC 3291).
 507: 
 508:                    ipv6(2)      A global IPv6 address as defined by the
 509:                                 InetAddressIPv6 TEXTUAL-CONVENTION (RFC 3291).
 510: 
 511:                    asnumber(3)  An Autonomous System (AS) number as defined
 512:                                 by the TeHopAddressAS TEXTUAL-CONVENTION.
 513: 
 514:                    unnum(4)     An unnumbered interface index as defined by
 515:                                 the TeHopAddressUnnum TEXTUAL-CONVETION.
 516: 
 517:                    lspid(5)     An LSP ID for CR-LDP Tunnels (RFC 3212) as
 518:                                 defined by the MplsLSPID TEXTUAL-CONVENTION.
 519: 
 520:                    Each definition of a concrete TeHopAddress value must
 521:                    be accompanied by a definition of a textual convention
 522:                    for use with that TeHopAddressType.
 523: 
 524:                    To support future extensions, the TeHopAddressType
 525:                    TEXTUAL-CONVENTION SHOULD NOT be sub-typed in object
 526:                    type definitions.  It MAY be sub-typed in compliance
 527:                    statements in order to require only a subset of these
 528:                    address types for a compliant implementation.
 529: 
 530:                    Implementations must ensure that TeHopAddressType objects
 531:                    and any dependent objects (e.g. TeHopAddress objects) are
 532:                    consistent.  An inconsistentValue error must be generated
 533:                    if an attempt to change a TeHopAddressType object would,
 534:                    for example, lead to an undefined TeHopAddress value.
 535:                    In particular, TeHopAddressType/TeHopAddress pairs
 536:                    must be changed together if the address type changes
 537:                    (e.g. from ipv6(3) to ipv4(2))."
 538:              REFERENCE
 539:                   "Textual Conventions for Internet Network
 540:                    Addresses, RFC3291.
 541: 
 542:                    Constraint-Based LSP Setup using LDP,
 543:                    RFC3212."
 544: 
 545:              SYNTAX     INTEGER {
 546:                            unknown(0),
 547:                            ipv4(1),
 548:                            ipv6(2),
 549:                            asnumber(3),
 550:                            unnum(4),
 551:                            lspid(5)
 552:                         }
 553: 
 554: 
 555:           TeHopAddress ::= TEXTUAL-CONVENTION

 556:              STATUS     current
 557:              DESCRIPTION
 558:                 "Denotes a generic Tunnel hop address.
 559: 
 560:                  A TeHopAddress value is always interpreted within the
 561:                  context of an TeHopAddressType value. Every usage of the
 562:                  TeHopInetAddress TEXTUAL-CONVENTION is required to specify
 563:                  the TeHopAddressType object which provides the context.
 564:                  It is suggested that the TeHopAddressType object is
 565:                  logically registered before the object(s) which use the
 566:                  TeHopAddress TEXTUAL-CONVENTION if they appear in the
 567:                  same logical row.
 568: 
 569:                  The value of a TeHopAddress object must always be
 570:                  consistent with the value of the associated
 571:                  TeHopAddressType object. Attempts to set a TeHopAddress
 572:                  object to a value which is inconsistent with the
 573:                  associated TeHopAddressType must fail with an
 574:                  inconsistentValue error.
 575: 
 576:                  When this TEXTUAL-CONVENTION is used as the syntax of an
 577:                  index object, there may be issues which the limit of 128
 578:                  sub-identifiers specified in SMIv2, STD 58. In this case,
 579:                  the object definition MUST include a 'SIZE' clause to
 580:                  limit the number of potential instance sub-identifiers."
 581:              SYNTAX     OCTET STRING (SIZE (0..255))
 582: 
 583:           TeHopAddressAS ::= TEXTUAL-CONVENTION

 584:              STATUS      current
 585:              DESCRIPTION
 586:                 "Represents a two or four octet AS number.
 587:                  The AS number is represented in network byte
 588:                  order (MSB first).  A two-octet AS number has
 589:                  the two MSB octets set to zero."
 590:              SYNTAX      OCTET STRING (SIZE (4))
 591: 
 592: 
 593:           TeHopAddressUnnum ::= TEXTUAL-CONVENTION

 594:              STATUS      current
 595:              DESCRIPTION
 596:                 "Represents an unnumbered interface:
 597: 
 598:                  octets   contents               encoding
 599:                   1-4      unnumbered interface   network-byte order
 600: 
 601:                  The corresponding TeHopAddressType value is unnum(5)."
 602:              SYNTAX      OCTET STRING(SIZE(4))
 603: 
 604: 
 605:      END
 606: 
 607: -- 
 608: --    Copyright (C) The Internet Society (2003). All Rights Reserved.
 609: -- 
 610: -- 
 611: --    This document and translations of it may be copied and furnished to
 612: --    others, and derivative works that comment on or otherwise explain it
 613: --    or assist in its implementation may be prepared, copied, published
 614: --    and distributed, in whole or in part, without restriction of any
 615: --    kind, provided that the above copyright notice and this paragraph are
 616: --    included on all such copies and derivative works.  However, this
 617: --    document itself may not be modified in any way, such as by removing
 618: --    the copyright notice or references to the Internet Society or other
 619: --    Internet organizations, except as needed for the  purpose of
 620: --    developing Internet standards in which case the procedures for
 621: --    copyrights defined in the Internet Standards process must be
 622: --    followed, or as required to translate it into languages other than
 623: --    English.
 624: -- 
 625: --    The limited permissions granted above are perpetual and will not be
 626: --    revoked by the Internet Society or its successors or assigns.
 627: -- 
 628: --    This document and the information contained herein is provided on an
 629: --    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 630: --    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 631: --    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 632: --    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 633: --    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 634: