📄 rfc2514.txt
字号:
Network Working Group M. NotoRequest for Comments: 2514 3ComCategory: Standards Track E. Spiegel Cisco Systems K. Tesink Bellcore Editors February 1999 Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM ManagementStatus 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 .............................. 20Abstract 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 SpiegelNoto, 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]) -- The Textual Conventions defined below are organized -- 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 PVCNoto, 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 toan svcOutgoing or an spvcTarget, and an spvcTarget is eithercross-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) - 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 {
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -