📄 rfc2514.txt
字号:
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])
-- 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 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)
- 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 + -