GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2514

Network Working Group M. Noto Request for Comments: 2514 3Com Category: Standards Track E. Spiegel

                                                        Cisco Systems
                                                            K. Tesink
                                                             Bellcore
                                                              Editors
                                                        February 1999
      Definitions of Textual Conventions and OBJECT-IDENTITIES
                         for ATM Management

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (1999).  All Rights Reserved.
 Table of Contents
 1 Introduction ..........................................    2
 2 Definitions ...........................................    3
 3 Acknowledgments .......................................   17
 4 References ............................................   17
 5 Security Considerations ...............................   17
 6 Authors' Addresses ....................................   18
 7 Intellectual Property .................................   19
 8 Full Copyright Statement ..............................   20

Abstract

 This memo describes Textual Conventions and OBJECT-IDENTITIES used
 for managing ATM-based interfaces, devices, networks and services.

1. Introduction

 This memo describes Textual Conventions and OBJECT-IDENTITIES used
 for managing ATM-based interfaces, devices, networks and services.

Noto, et. al. Standards Track [Page 1] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

 When designing a MIB module, it is often useful to define new types
 similar to those defined in the SMI.  In comparison to a type defined
 in the SMI, each of these new types has a different name, a similar
 syntax, but a more precise semantics.  These newly defined types are
 termed textual conventions, and are used for the convenience of
 humans reading the MIB module.  This is done through Textual
 Conventions as defined in RFC1903 [1].  It is the purpose of this
 document to define the set of textual conventions available to ATM
 MIB modules.
 When designing MIB modules, it is also often useful to register
 further properties with object identifier assignments so that they
 can be further used by other MIB modules.  This is done through the
 OBJECT-IDENTITY macro defined in RFC1902 [2].  This document defines
 OBJECT-IDENTITIES available to ATM MIB modules.
 Note that for organizational purposes OBJECT IDENTITIES previously
 defined in RFC1695 have been moved to this specification and no
 longer appear in the revision of RFC1695 [3]. However, the original
 OBJECT IDENTIFIERs have been preserved.
 For an introduction to the concepts of ATM connections, see [3].

2. Definitions

   ATM-TC-MIB DEFINITIONS ::= BEGIN
   IMPORTS
      MODULE-IDENTITY, OBJECT-IDENTITY,
      TimeTicks, mib-2
          FROM SNMPv2-SMI
      TEXTUAL-CONVENTION
          FROM SNMPv2-TC;
   atmTCMIB MODULE-IDENTITY
        LAST-UPDATED "9810190200Z"
        ORGANIZATION "IETF AToMMIB Working Group"
        CONTACT-INFO
          "          Michael Noto
            Postal:  3Com Corporation
                     5400 Bayfront Plaza, M/S 3109
                     Santa Clara, CA 95052
                     USA
            Tel:     +1 408 326 2218
            E-mail:  mike_noto@3com.com
                     Ethan Mickey Spiegel

Noto, et. al. Standards Track [Page 2] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

            Postal:  Cisco Systems
                     170 W. Tasman Dr.
                     San Jose, CA 95134
                     USA
            Tel:     +1 408 526 6408
            E-mail:  mspiegel@cisco.com
                     Kaj Tesink
            Postal:  Bellcore
                     331 Newman Springs Road
                     Red Bank, NJ 07701
                     USA
            Tel:     +1 732 758 5254
            Fax:     +1 732 758 4177
            E-mail:  kaj@bellcore.com"
        DESCRIPTION
         "This MIB Module provides Textual Conventions
         and OBJECT-IDENTITY Objects to be used by
         ATM systems."
        ::= { mib-2 37 3 } -- atmMIB 3 (see [3])
  1. - The Textual Conventions defined below are organized
  2. - alphabetically
   AtmAddr ::= TEXTUAL-CONVENTION
           DISPLAY-HINT "1x"
           STATUS  current
           DESCRIPTION
               "An ATM address. The semantics are implied by
               the length. The address types are: - no
               address (0 octets) - E.164 (8 octets) - NSAP
               (20 octets) In addition, when subaddresses
               are used the AtmAddr may represent the
               concatenation of address and subaddress. The
               associated address types are: - E.164, E.164
               (16 octets) - E.164, NSAP (28 octets) - NSAP,
               NSAP (40 octets) Address lengths other than
               defined in this definition imply address
               types defined elsewhere.  Note: The E.164
               address is encoded in BCD format."
          SYNTAX   OCTET STRING (SIZE(0..40))
  AtmConnCastType ::= TEXTUAL-CONVENTION
          STATUS  current
          DESCRIPTION
            "The type of topology of a connection (point-

Noto, et. al. Standards Track [Page 3] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

            to-point, point-to-multipoint). In the case
            of point-to-multipoint, the orientation of
            this VPL or VCL in the connection.
            On a host:
            - p2mpRoot indicates that the host
              is the root of the p2mp connection.
            - p2mpLeaf indicates that the host
              is a leaf of the p2mp connection.
            On a switch interface:
            - p2mpRoot indicates that cells received
              by the switching fabric from the interface
              are from the root of the p2mp connection.
            - p2mpLeaf indicates that cells transmitted
              to the interface from the switching fabric
              are to the leaf of the p2mp connection."
          SYNTAX   INTEGER {
             p2p(1),
             p2mpRoot(2),
             p2mpLeaf(3)
             }
  AtmConnKind ::= TEXTUAL-CONVENTION
          STATUS  current
          DESCRIPTION
              "The type of call control used for an ATM
              connection at a particular interface. The use
              is as follows:
                 pvc(1)
                    Virtual link of a PVC. Should not be
                    used for an PVC/SVC (i.e., Soft PVC)
                    crossconnect.
                 svcIncoming(2)
                    Virtual link established after a
                    received signaling request to setup
                    an SVC.
                 svcOutgoing(3)
                    Virtual link established after a
                    transmitted or forwarded signaling
                    request to setup an SVC.
                 spvcInitiator(4)
                    Virtual link at the PVC side of an
                    SVC/PVC crossconnect, where the
                    switch is the initiator of the Soft PVC
                    setup.
                 spvcTarget(5)
                    Virtual link at the PVC side of an
                    SVC/PVC crossconnect, where the
                    switch is the target of the Soft PVC

Noto, et. al. Standards Track [Page 4] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

                    setup.
              For PVCs, a pvc virtual link is always cross-
              connected to a pvc virtual link.
              For SVCs, an svcIncoming virtual link is always cross-
              connected to an svcOutgoing virtual link.

For Soft PVCs, an spvcInitiator is either cross-connected to an svcOutgoing or an spvcTarget, and an spvcTarget is either cross-connected to an svcIncoming or an spvcInitiator."

      SYNTAX   INTEGER {
         pvc(1),
         svcIncoming(2),
         svcOutgoing(3),
         spvcInitiator(4),
         spvcTarget(5)
         }
  AtmIlmiNetworkPrefix ::= TEXTUAL-CONVENTION
      STATUS   current
      DESCRIPTION
          "A network prefix used for ILMI address
          registration.  In the case of ATM endsystem
          addresses (AESAs), the network prefix is the first
          13 octets of the address which includes the AFI,
          IDI, and HO-DSP fields.  In the case of native
          E.164 addresses, the network prefix is the entire
          E.164 address encoded in 8 octets, as if it were
          an E.164 IDP in an ATM endsystem address
          structure."
      REFERENCE
          "ATM Forum, Integrated Local Management Interface
             (ILMI) Specification, Version 4.0,
             af-ilmi-0065.000, September 1996, Section 9
           ATM Forum, ATM User-Network Interface Signalling
             Specification, Version 4.0 (UNI 4.0),
             af-sig-0061.000, June 1996, Section 3"
      SYNTAX   OCTET STRING (SIZE(8|13))

AtmInterfaceType ::= TEXTUAL-CONVENTION

      STATUS       current
      DESCRIPTION
          "The connection setup procedures used for the
          identified interface.
          Other: Connection setup procedures other than
             those listed below.

Noto, et. al. Standards Track [Page 5] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

          Auto-configuration:
             Indicates that the connection setup
             procedures are to be determined dynamically,
             or that determination has not yet been
             completed. One such mechanism is via ATM
             Forum ILMI auto-configuration procedures.
          ITU-T DSS2:
          -  ITU-T Recommendation Q.2931, Broadband
             Integrated Service Digital Network (B-ISDN)
             Digital Subscriber Signalling System No.2
             (DSS2) User-Network Interface (UNI) Layer 3
             Specification for Basic Call/Connection
             Control (September 1994)
          -  ITU-T Draft Recommendation Q.2961,
             B-ISDN DSS 2 Support of Additional Traffic
             Parameters (May 1995)
  1. ITU-T Draft Recommendation Q.2971,

B-ISDN DSS 2 User Network Interface Layer 3

             Specification for Point-to-multipoint
             Call/connection Control (May 1995)
          ATM Forum UNI 3.0:
             ATM Forum, ATM User-Network Interface,
             Version 3.0 (UNI 3.0) Specification,
             (1994).
          ATM Forum UNI 3.1:
             ATM Forum, ATM User-Network Interface,
             Version 3.1 (UNI 3.1) Specification,
             (November 1994).
          ATM Forum UNI Signalling 4.0:
             ATM Forum, ATM User-Network Interface (UNI)
             Signalling Specification Version 4.0,
             af-sig-0061.000 (June 1996).
          ATM Forum IISP (based on UNI 3.0 or UNI 3.1) :
             Interim Inter-switch Signaling Protocol
             (IISP) Specification, Version 1.0,
             af-pnni-0026.000, (December 1994).
          ATM Forum PNNI 1.0 :
             ATM Forum, Private Network-Network Interface
             Specification, Version 1.0, af-pnni-0055.000,
             (March 1996).

Noto, et. al. Standards Track [Page 6] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

          ATM Forum B-ICI:
             ATM Forum, B-ICI Specification, Version 2.0,
             af-bici-0013.002, (November 1995).
          ATM Forum UNI PVC Only:
             An ATM Forum compliant UNI with the
             signalling disabled.
          ATM Forum NNI PVC Only:
             An ATM Forum compliant NNI with the
             signalling disabled."
      SYNTAX  INTEGER  {
                other(1),
                autoConfig(2),
                ituDss2(3),
                atmfUni3Dot0(4),
                atmfUni3Dot1(5),
                atmfUni4Dot0(6),
                atmfIispUni3Dot0(7),
                atmfIispUni3Dot1(8),
                atmfIispUni4Dot0(9),
      atmfPnni1Dot0(10),
      atmfBici2Dot0(11),
      atmfUniPvcOnly(12),
      atmfNniPvcOnly(13)  }

AtmServiceCategory ::= TEXTUAL-CONVENTION

      STATUS  current
      DESCRIPTION
          "The service category for a connection."
      REFERENCE
          "ATM Forum Traffic Management Specification,
          Version 4.0, af-tm-0056.000, June 1996."
      SYNTAX   INTEGER {
         other(1),   -- none of the following
         cbr(2),     -- constant bit rate
         rtVbr(3),   -- real-time variable bit rate
         nrtVbr(4),  -- non real-time variable bit rate
         abr(5),     -- available bit rate
         ubr(6)      -- unspecified bit rate
         }

AtmSigDescrParamIndex ::= TEXTUAL-CONVENTION

      STATUS  current
      DESCRIPTION
          "The value of this object identifies a row in the
          atmSigDescrParamTable. The value 0 signifies that
          none of the signalling parameters defined in the
          atmSigDescrParamTable are applicable."

Noto, et. al. Standards Track [Page 7] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

      SYNTAX  INTEGER (0..2147483647)

AtmTrafficDescrParamIndex ::= TEXTUAL-CONVENTION

      STATUS  current
      DESCRIPTION
          "The value of this object identifies a row in the
          atmTrafficDescrParamTable.  The value 0 signifies
          that no row has been identified."
      SYNTAX  INTEGER (0..2147483647)

AtmVcIdentifier ::= TEXTUAL-CONVENTION

      STATUS  current
      DESCRIPTION
          "The VCI value for a VCL. The maximum VCI value
          cannot exceed the value allowable by
          atmInterfaceMaxVciBits defined in ATM-MIB."
      SYNTAX   INTEGER (0..65535)

AtmVpIdentifier ::= TEXTUAL-CONVENTION

      STATUS  current
      DESCRIPTION
          "The VPI value for a VPL or VCL. The value VPI=0
          is only allowed for a VCL. For ATM UNIs supporting
          VPCs the VPI value ranges from 0 to 255.  The VPI
          value 0 is supported for ATM UNIs conforming to
          the ATM Forum UNI 4.0 Annex 8 (Virtual UNIs)
          specification. For ATM UNIs supporting VCCs the
          VPI value ranges from 0 to 255.  For ATM NNIs the
          VPI value ranges from 0 to 4095.  The maximum VPI
          value cannot exceed the value allowable by
          atmInterfaceMaxVpiBits defined in ATM-MIB."
      SYNTAX    INTEGER (0..4095)

AtmVorXAdminStatus ::= TEXTUAL-CONVENTION

      STATUS  current
      DESCRIPTION
          "The value determines the desired administrative
          status of a virtual link or cross-connect. The up
          and down states indicate that the traffic flow is
          enabled or disabled respectively on the virtual
          link or cross-connect."
      SYNTAX   INTEGER {
         up(1),
         down(2)
          }

AtmVorXLastChange ::= TEXTUAL-CONVENTION

      STATUS  current

Noto, et. al. Standards Track [Page 8] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

      DESCRIPTION
          "The value of MIB II's sysUpTime at the time a
          virtual link or cross-connect entered its current
          operational state. If the current state was
          entered prior to the last re-initialization of the
          agent then this object contains a zero value."
      SYNTAX   TimeTicks

AtmVorXOperStatus ::= TEXTUAL-CONVENTION

      STATUS  current
      DESCRIPTION
          "The value determines the operational status of a
          virtual link or cross-connect. The up and down
          states indicate that the traffic flow is enabled
          or disabled respectively on the virtual link or
          cross-connect. The unknown state indicates that
          the state of it cannot be determined. The state
          will be down or unknown if the supporting ATM
          interface(s) is down or unknown respectively."
      SYNTAX   INTEGER {
         up(1),
         down(2),
         unknown(3)
         }

– OBJECT-IDENTITIES:

– The following atmTrafficDescriptorTypes has been moved – from RFC1695 and no longer appear in the revision of – RFC1695[3].

atmTrafficDescriptorTypes OBJECT IDENTIFIER ::= {mib-2 37 1 1}

  1. - atmMIBObjects
  2. - See [3].

– All other and new OBJECT IDENTITIES – are defined under the following subtree:

  atmObjectIdentities OBJECT IDENTIFIER ::= {atmTCMIB 1}

– The following values are defined for use as – possible values of the ATM traffic descriptor type.

atmNoTrafficDescriptor OBJECT-IDENTITY

  STATUS  deprecated

Noto, et. al. Standards Track [Page 9] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

  DESCRIPTION
      "This identifies the no ATM traffic
      descriptor type.  Parameters 1, 2, 3, 4,
      and 5 are not used.  This traffic descriptor
      type can be used for best effort traffic."
  ::= {atmTrafficDescriptorTypes 1}

atmNoClpNoScr OBJECT-IDENTITY

  STATUS  current
  DESCRIPTION
      "This traffic descriptor type is for no CLP
      and no Sustained Cell Rate.  The use of the
      parameter vector for this type:
      Parameter 1: peak cell rate in cells/second
                   for CLP=0+1 traffic
      Parameter 2: not used
      Parameter 3: not used
      Parameter 4: not used
      Parameter 5: not used."
  REFERENCE
      "ATM Forum,ATM User-Network Interface,
         Version 3.0 (UNI 3.0) Specification, 1994.
       ATM Forum, ATM User-Network Interface,
         Version 3.1 (UNI 3.1) Specification,
         November 1994."
  ::= {atmTrafficDescriptorTypes 2}

atmClpNoTaggingNoScr OBJECT-IDENTITY

  STATUS  deprecated
  DESCRIPTION
      "This traffic descriptor is for CLP without
      tagging and no Sustained Cell Rate.  The use
      of the parameter vector for this type:
      Parameter 1: peak cell rate in cells/second
                   for CLP=0+1 traffic
      Parameter 2: peak cell rate in cells/second
                   for CLP=0 traffic
      Parameter 3: not used
      Parameter 4: not used
      Parameter 5: not used."
  ::= {atmTrafficDescriptorTypes 3}

atmClpTaggingNoScr OBJECT-IDENTITY

  STATUS  deprecated
  DESCRIPTION
      "This traffic descriptor is for CLP with
      tagging and no Sustained Cell Rate.  The use
      of the parameter vector for this type:

Noto, et. al. Standards Track [Page 10] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

      Parameter 1: peak cell rate in cells/second
                   for CLP=0+1 traffic
      Parameter 2: peak cell rate in cells/second
                   for CLP=0 traffic, excess
                   tagged as CLP=1
      Parameter 3: not used
      Parameter 4: not used
      Parameter 5: not used."
  ::= {atmTrafficDescriptorTypes 4}

atmNoClpScr OBJECT-IDENTITY

  STATUS  current
  DESCRIPTION
      "This traffic descriptor type is for no CLP
      with Sustained Cell Rate.  The use of the
      parameter vector for this type:
      Parameter 1: peak cell rate in cells/second
                   for CLP=0+1 traffic
      Parameter 2: sustainable cell rate in cells/second
                   for CLP=0+1 traffic
      Parameter 3: maximum burst size in cells
      Parameter 4: not used
      Parameter 5: not used."
  REFERENCE
      "ATM Forum,ATM User-Network Interface,
         Version 3.0 (UNI 3.0) Specification, 1994.
       ATM Forum, ATM User-Network Interface,
         Version 3.1 (UNI 3.1) Specification,
         November 1994."
  ::= {atmTrafficDescriptorTypes 5}

atmClpNoTaggingScr OBJECT-IDENTITY

  STATUS  current
  DESCRIPTION
      "This traffic descriptor type is for CLP with
      Sustained Cell Rate and no tagging.  The use
      of the parameter vector for this type:
      Parameter 1: peak cell rate in cells/second
                   for CLP=0+1 traffic
      Parameter 2: sustainable cell rate in cells/second
                   for CLP=0 traffic
      Parameter 3: maximum burst size in cells
      Parameter 4: not used
      Parameter 5: not used."
  REFERENCE
      "ATM Forum,ATM User-Network Interface,
         Version 3.0 (UNI 3.0) Specification, 1994.
       ATM Forum, ATM User-Network Interface,

Noto, et. al. Standards Track [Page 11] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

         Version 3.1 (UNI 3.1) Specification,
         November 1994."
  ::= {atmTrafficDescriptorTypes 6}

atmClpTaggingScr OBJECT-IDENTITY

  STATUS  current
  DESCRIPTION
      "This traffic descriptor type is for CLP with
      tagging and Sustained Cell Rate.  The use of
      the parameter vector for this type:
      Parameter 1: peak cell rate in cells/second
                   for CLP=0+1 traffic
      Parameter 2: sustainable cell rate in cells/second
                   for CLP=0 traffic, excess tagged as
                   CLP=1
      Parameter 3: maximum burst size in cells
      Parameter 4: not used
      Parameter 5: not used."
  REFERENCE
      "ATM Forum,ATM User-Network Interface,
         Version 3.0 (UNI 3.0) Specification, 1994.
       ATM Forum, ATM User-Network Interface,
         Version 3.1 (UNI 3.1) Specification,
         November 1994."
  ::= {atmTrafficDescriptorTypes 7}

atmClpNoTaggingMcr OBJECT-IDENTITY

  STATUS  current
  DESCRIPTION
      "This traffic descriptor type is for CLP with
      Minimum Cell Rate and no tagging.  The use of
      the parameter vector for this type:
      Parameter 1: peak cell rate in cells/second
                   for CLP=0+1 traffic
      Parameter 2: CDVT in tenths of microseconds
      Parameter 3: minimum cell rate in cells/second
      Parameter 4: unused
      Parameter 5: unused."
  REFERENCE
      "ATM Forum,ATM User-Network Interface,
         Version 3.0 (UNI 3.0) Specification, 1994.
       ATM Forum, ATM User-Network Interface,
         Version 3.1 (UNI 3.1) Specification,
         November 1994."
  ::= {atmTrafficDescriptorTypes 8}

atmClpTransparentNoScr OBJECT-IDENTITY

  STATUS  current

Noto, et. al. Standards Track [Page 12] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

  DESCRIPTION
      "This traffic descriptor type is for the CLP-
      transparent model and no Sustained Cell Rate.
      The use of the parameter vector for this type:
      Parameter 1: peak cell rate in cells/second
                   for CLP=0+1 traffic
      Parameter 2: CDVT in tenths of microseconds
      Parameter 3: not used
      Parameter 4: not used
      Parameter 5: not used.
      This traffic descriptor type is applicable to
      connections following the CBR.1 conformance
      definition.
      Connections specifying this traffic descriptor
      type will be rejected at UNI 3.0 or UNI 3.1
      interfaces.  For a similar traffic descriptor
      type that can be accepted at UNI 3.0 and
      UNI 3.1 interfaces, see atmNoClpNoScr."
  REFERENCE
      "ATM Forum,ATM User-Network Interface,
         Version 3.0 (UNI 3.0) Specification, 1994.
       ATM Forum, ATM User-Network Interface,
         Version 3.1 (UNI 3.1) Specification,
         November 1994.
       ATM Forum, Traffic Management Specification,
         Version 4.0, af-tm-0056.000, June 1996."
  ::= {atmTrafficDescriptorTypes 9}

atmClpTransparentScr OBJECT-IDENTITY

  STATUS  current
  DESCRIPTION
      "This traffic descriptor type is for the CLP-
      transparent model with Sustained Cell Rate.
      The use of the parameter vector for this type:
      Parameter 1: peak cell rate in cells/second
                   for CLP=0+1 traffic
      Parameter 2: sustainable cell rate in cells/second
                   for CLP=0+1 traffic
      Parameter 3: maximum burst size in cells
      Parameter 4: CDVT in tenths of microseconds
      Parameter 5: not used.
      This traffic descriptor type is applicable to
      connections following the VBR.1 conformance
      definition.

Noto, et. al. Standards Track [Page 13] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

      Connections specifying this traffic descriptor
      type will be rejected at UNI 3.0 or UNI 3.1
      interfaces.  For a similar traffic descriptor
      type that can be accepted at UNI 3.0 and
      UNI 3.1 interfaces, see atmNoClpScr."
  REFERENCE
      "ATM Forum,ATM User-Network Interface,
         Version 3.0 (UNI 3.0) Specification, 1994.
       ATM Forum, ATM User-Network Interface,
         Version 3.1 (UNI 3.1) Specification,
         November 1994.
       ATM Forum, Traffic Management Specification,
         Version 4.0, af-tm-0056.000, June 1996."
  ::= {atmTrafficDescriptorTypes 10}

atmNoClpTaggingNoScr OBJECT-IDENTITY

  STATUS  current
  DESCRIPTION
      "This traffic descriptor type is for no CLP
      with tagging and no Sustained Cell Rate.  The
      use of the parameter vector for this type:
      Parameter 1: peak cell rate in cells/second
                   for CLP=0+1 traffic
      Parameter 2: CDVT in tenths of microseconds
      Parameter 3: not used
      Parameter 4: not used
      Parameter 5: not used.
      This traffic descriptor type is applicable to
      connections following the UBR.2 conformance
      definition ."
  REFERENCE
      "ATM Forum,ATM User-Network Interface,
         Version 3.0 (UNI 3.0) Specification, 1994.
       ATM Forum, ATM User-Network Interface,
         Version 3.1 (UNI 3.1) Specification,
         November 1994.
       ATM Forum, Traffic Management Specification,
         Version 4.0, af-tm-0056.000, June 1996."
  ::= {atmTrafficDescriptorTypes 11}

atmNoClpNoScrCdvt OBJECT-IDENTITY

  STATUS  current
  DESCRIPTION
      "This traffic descriptor type is for no CLP
      and no Sustained Cell Rate.  The use of the
      parameter vector for this type:
      Parameter 1: peak cell rate in cells/second

Noto, et. al. Standards Track [Page 14] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

                   for CLP=0+1 traffic
      Parameter 2: CDVT in tenths of microseconds
      Parameter 3: not used
      Parameter 4: not used
      Parameter 5: not used.
      This traffic descriptor type is applicable to
      CBR connections following the UNI 3.0/3.1
      conformance definition for PCR CLP=0+1.
      These CBR connections differ from CBR.1
      connections in that the CLR objective
      applies only to the CLP=0 cell flow.
      This traffic descriptor type is also
      applicable to connections following the UBR.1
      conformance definition."
  REFERENCE
      "ATM Forum,ATM User-Network Interface,
         Version 3.0 (UNI 3.0) Specification, 1994.
       ATM Forum, ATM User-Network Interface,
         Version 3.1 (UNI 3.1) Specification,
         November 1994.
       ATM Forum, Traffic Management Specification,
         Version 4.0, af-tm-0056.000, June 1996."
  ::= {atmTrafficDescriptorTypes 12}

atmNoClpScrCdvt OBJECT-IDENTITY

  STATUS  current
  DESCRIPTION
      "This traffic descriptor type is for no CLP
      with Sustained Cell Rate.  The use of the
      parameter vector for this type:
      Parameter 1: peak cell rate in cells/second
                   for CLP=0+1 traffic
      Parameter 2: sustainable cell rate in cells/second
                   for CLP=0+1 traffic
      Parameter 3: maximum burst size in cells
      Parameter 4: CDVT in tenths of microseconds
      Parameter 5: not used.
      This traffic descriptor type is applicable
      to VBR connections following the UNI 3.0/3.1
      conformance definition for PCR CLP=0+1 and
      SCR CLP=0+1.  These VBR connections
      differ from VBR.1 connections in that
      the CLR objective applies only to the CLP=0
      cell flow."
  REFERENCE

Noto, et. al. Standards Track [Page 15] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

      "ATM Forum,ATM User-Network Interface,
         Version 3.0 (UNI 3.0) Specification, 1994.
       ATM Forum, ATM User-Network Interface,
         Version 3.1 (UNI 3.1) Specification,
         November 1994.
       ATM Forum, Traffic Management Specification,
         Version 4.0, af-tm-0056.000, June 1996."
  ::= {atmTrafficDescriptorTypes 13}

atmClpNoTaggingScrCdvt OBJECT-IDENTITY

  STATUS  current
  DESCRIPTION
      "This traffic descriptor type is for CLP with
      Sustained Cell Rate and no tagging.  The use
      of the parameter vector for this type:
      Parameter 1: peak cell rate in cells/second
                   for CLP=0+1 traffic
      Parameter 2: sustainable cell rate in cells/second
                   for CLP=0 traffic
      Parameter 3: maximum burst size in cells
      Parameter 4: CDVT in tenths of microseconds
      Parameter 5: not used.
      This traffic descriptor type is applicable to
      connections following the VBR.2 conformance
      definition."
  REFERENCE
      "ATM Forum,ATM User-Network Interface,
         Version 3.0 (UNI 3.0) Specification, 1994.
       ATM Forum, ATM User-Network Interface,
         Version 3.1 (UNI 3.1) Specification,
         November 1994.
       ATM Forum, Traffic Management Specification,
         Version 4.0, af-tm-0056.000, June 1996."
  ::= {atmTrafficDescriptorTypes 14}

atmClpTaggingScrCdvt OBJECT-IDENTITY

  STATUS  current
  DESCRIPTION
      "This traffic descriptor type is for CLP with
      tagging and Sustained Cell Rate.  The use of
      the parameter vector for this type:
      Parameter 1: peak cell rate in cells/second
                   for CLP=0+1 traffic
      Parameter 2: sustainable cell rate in cells/second
                   for CLP=0 traffic, excess tagged as
                   CLP=1
      Parameter 3: maximum burst size in cells

Noto, et. al. Standards Track [Page 16] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

      Parameter 4: CDVT in tenths of microseconds
      Parameter 5: not used.
      This traffic descriptor type is applicable to
      connections following the VBR.3 conformance
      definition."
  REFERENCE
      "ATM Forum,ATM User-Network Interface,
         Version 3.0 (UNI 3.0) Specification, 1994.
       ATM Forum, ATM User-Network Interface,
         Version 3.1 (UNI 3.1) Specification,
         November 1994.
       ATM Forum, Traffic Management Specification,
         Version 4.0, af-tm-0056.000, June 1996."
  ::= {atmTrafficDescriptorTypes 15}

END

3. Acknowledgments

 This document is a product of the AToMMIB Working Group.

4. References

 [1]  Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
      "Textual Conventions for Version 2 of the Simple Network
      Management Protocol (SNMPv2)", RFC 1903, January 1996.
 [2]  Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Structure
      of Management Information for Version 2 of the Simple Network
      Management Protocol (SNMPv2)", RFC 1902, January 1996.
 [3]  Tesink, K., Editor, "Definitions of Managed Objects for ATM
      Management", RFC 2515, February 1999.

5. Security Considerations

 This memo defines textual conventions and object identities for use
 in ATM MIB modules. Security issues for these MIB modules are
 addressed in the memos defining those modules.

Noto, et. al. Standards Track [Page 17] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

6. Authors' Addresses

 Michael Noto
 3Com Corporation
 5400 Bayfront Plaza, M/S 3109
 Santa Clara, CA 95052
 Phone +1 408 326 2218
 Email: mike_noto@3com.com
 Ethan Mickey Spiegel
 Cisco Systems
 170 W. Tasman Dr.
 San Jose, CA 95134
 USA
 Phone +1 408 526 6408
 EMail: mspiegel@cisco.com
 Kaj Tesink
 Bellcore
 331 Newman Springs Road
 P.O. Box 7020
 Red Bank, NJ  07701-7020
 Phone: (732) 758-5254
 EMail: kaj@bellcore.com

Noto, et. al. Standards Track [Page 18] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

7. Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 intellectual property or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; neither does it represent that it
 has made any effort to identify any such rights.  Information on the
 IETF's procedures with respect to rights in standards-track and
 standards-related documentation can be found in BCP-11.  Copies of
 claims of rights made available for publication and any assurances of
 licenses to be made available, or the result of an attempt made to
 obtain a general license or permission for the use of such
 proprietary rights by implementors or users of this specification can
 be obtained from the IETF Secretariat.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights which may cover technology that may be required to practice
 this standard.  Please address the information to the IETF Executive
 Director.

Noto, et. al. Standards Track [Page 19] RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999

8. Full Copyright Statement

 Copyright (C) The Internet Society (1999).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Noto, et. al. Standards Track [Page 20]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2514.txt · Last modified: 1999/02/05 23:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki