As per Relevance of the word indicate, we have this rfc below:











Network Working Group B.
Request for Comments: 2455 Cisco
Obsoletes: 2155 B.
Category: Standards Track IBM
November 1998


Definitions of Managed
for

Status of this

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

Copyright

Copyright (C) The Internet Society (1998). All Rights Reserved



This memo defines a portion of the Management Information Base (MIB
for use with network management protocols in the Internet community
In particular, it defines objects for monitoring and
network devices with APPN (Advanced Peer-to-Peer Networking
capabilities. This memo identifies managed objects for the
protocol

Table of

1. Introduction .......................................... 2
2. The SNMPv2 Network Management Framework ............... 2
3. Overview .............................................. 3
3.1 Relationship with RFC 2155 ........................... 6
3.2 APPN MIB structure ................................... 7
4. Definitions ........................................... 10
5. Security Considerations ............................... 135
6. Intellectual Property ................................. 136
7. Acknowledgments ....................................... 137
8. References ............................................ 137
9. Authors' Addresses .................................... 139
10. Full Copyright Statement .............................. 140






Clouston & Moore Standards Track [Page 1]

RFC 2455 APPN MIB November 1998


1.

This document is a product of the SNA NAU Services MIB Working Group
It defines a MIB module for managing devices with Advanced Peer-to
Peer Networking (APPN) capabilities

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [17].

2. The SNMP Network Management

The SNMP Management Framework presently consists of five
components

o An overall architecture, described in RFC 2271 [1].

o Mechanisms for describing and naming objects and events for
purpose of management. The first version of this Structure
Management Information (SMI) is called SMIv1 and described
STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4].
second version, called SMIv2, is described in RFC 1902 [5],
1903 [6] and RFC 1904 [7].

o Message protocols for transferring management information.
first version of the SNMP message protocol is called SNMPv1
described in STD 15, RFC 1157 [8]. A second version of the
message protocol, which is not an Internet standards
protocol, is called SNMPv2c and described in RFC 1901 [9]
RFC 1906 [10]. The third version of the message protocol
called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11]
RFC 2274 [12].

o Protocol operations for accessing management information.
first set of protocol operations and associated PDU formats
described in STD 15, RFC 1157 [8]. A second set of
operations and associated PDU formats is described in RFC 1905
[13].

o A set of fundamental applications described in RFC 2273 [14]
the view-based access control mechanism described in RFC 2275
[15].

Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the mechanisms defined in the SMI





Clouston & Moore Standards Track [Page 2]

RFC 2455 APPN MIB November 1998


This memo specifies a MIB module that is compliant to the SMIv2.
MIB conforming to the SMIv1 can be produced through the
translations. The resulting translated MIB must be
equivalent, except where objects or events are omitted because
translation is possible (use of Counter64). Some machine
information in SMIv2 will be converted into textual descriptions
SMIv1 during the translation process. However, this loss of
readable information is not considered to change the semantics of
MIB

3.

This document identifies a set of objects for monitoring
configuration and active characteristics of devices with
capabilities, and for controlling certain characteristics. APPN
the aspect of Systems Network Architecture (SNA) that supports peer
to-peer networking. These networks transport both independent
dependent LU session traffic. See the SNANAU APPC MIB [21] and
SNA NAU MIB [22] for management of these sessions. See also
2232, the DLUR MIB [23], and RFC 2238, the HPR MIB [24]
management of extensions to the APPN architecture. In this document
we describe APPN managed objects

An APPN network comprises various types of nodes, and
groups (TGs) that connect the nodes. Network nodes (NNs)
directory and routing functions for session establishment. NNs
be session end points or intermediate nodes in a session. A
node is a type of network node that connects networks together
session establishment without fully merging them. A branch
node (BrNN) is a network node that is similar to a border node,
with only minimal functions to build a large APPN network within
enterprise. Although a BrNN is defined to be a network node in
APPN architecture, it also has an end node (EN) appearance
upstream NNs in the network. In this MIB module it is treated as
separate node type since it does not fit cleanly as an EN or NN,
this module explicity identifies those objects returned by a BrNN
For example, a BrNN does not implement the appnNnTopo objects
it is the only node in its network topology table; but it
implement the appnSessIntermediate objects since it does
intermediate session support. It also implements two of
appnEnUniqueCaps objects that could be useful to a
application. A BrNN identifies itself as 'endNode' in
appnNodeType object but further identifies itself as a BrNN in
appnNodeBrNn object

End nodes are session end points that receive directory and
functions from network nodes, over control-point to control-
(CP-CP) sessions. Low-entry networking (LEN) nodes are also



Clouston & Moore Standards Track [Page 3]

RFC 2455 APPN MIB November 1998


end points, but do not support CP-CP sessions, and therefore
additional manual configuration definitions to establish sessions
an APPN network. ENs and LEN nodes may have minimal directory
routing functions to establish control sessions (ENs) or to
into the APPN network (LEN nodes).

Virtual routing nodes (VRNs) are not really nodes, but rather
definitions among actual nodes in a shared transport facility such
a local area network (LAN) that allow these actual nodes
temporarily establish a logical link with one another
defining each other's link-level addressing information

Ports and link stations are the node's interface to the data
control (DLC), which provides the physical transport, or to
protocol such as Data Link Switching (DLSw), which provides
over an IP network. See the SNADLC SDLC MIB[25], the SNADLC
MIB[26], and the DLSw MIB[27]. A link station uses a port to make
connection to another node. This connection establishes a TG
the two nodes

The directory and routing functions enable an NN to find where an
is located in the network, and calculate the optimal route for
session based on the requested class of service (COS). A
node saves the LU information in a directory database, which is
from LUs defined locally, LU registration from served end nodes,
LUs learned from network searches

Each NN maintains a local COS database that assigns a routing weight
or relative cost, to each resource for each class of service.
example, the #INTER COS assigns a lower weight to TGs with a
effective capacity, while the #BATCH COS favors TGs with a
relative cost per byte

A node saves network topology information (on NNs, VRNs, and
between them) in a network topology database. A node that
APPN function set 1120, branch awareness, also saves information
TGs to adjacent BrNNs. The topology information includes state
routing characteristics. Topology information is exchanged
NNs over CP-CP sessions such that the database is fully replicated
each NN. Information on TGs to all node types are kept in a
topology database. Local topology information is shared with
nodes only during the session establishment process, to give the
responsible for route calculation the necessary information for end
to-end route calculation

A management application can show a full representation of the
network from the network and local topology information. To show
network topology, the application need only query the



Clouston & Moore Standards Track [Page 4]

RFC 2455 APPN MIB November 1998


topology tables from a single NN. To show all of the BrNNs,
application must also directly query all destinations of TGs
indicate they are branch TGs (indicated by the
object) to see if they have any cascaded BrNNs. For any NNs that
not indicate branch awareness support (indicated by
appnNnNodeFRBranchAwareness object), the application must query
NN's appnLocalTgTable, and then the appnNodeBrNn object of each row'
destination node to identify BrNNs. To show all of the nodes in
network, including ENs and LEN nodes, the application must
every NN's appnLocalTgTable, and iteratively do the same for
BrNN it finds

SNA names such as LU names, CP names, COS names, and mode names
be padded with blanks (space characters) in SNA formats.
blanks are nonsignificant. For example, in a BIND Request Unit (RU
a COS name of "#INTER" with a length of 6 is identical to a COS
of "#INTER " with a length of 8. However, in this MIB
nonsignificant blanks are not included by the agent. Using the
name from the previous example, an agent would return a length of 6
and the string "#INTER" with no blanks for appnCosName, regardless
how it appears in the BIND RU or in internal storage. The
exception is the all blank mode name, for which the agent returns
length of 8 and the string " " (8 blank spaces). The
variables that this applies to are identified by a textual
syntax that also describes this behavior

When an SNA name is functioning as a table index, an agent
trailing blanks as significant. If a management station requests
objects from a row with index "#INTER ", the agent does not
this to the row with index "#INTER". Since an agent has
nonsignificant blanks in any of its table indices, the only
for a Management Station to include them would be to start
processing at a chosen point in a table. For example, a
request with index "M " would start retrieval from a table
the first row with an 8-character index beginning with "M" or
letter after "M".

The SNA/APPN terms and overall architecture are documented in [18],
[19], [20], and [28].

Highlights of the management functions supported by the APPN
module include the following

o Activating and deactivating ports and link stations

o Monitoring of configuration parameters related to the node
ports, link stations, virtual routing nodes, and classes
service



Clouston & Moore Standards Track [Page 5]

RFC 2455 APPN MIB November 1998


o Monitoring of operational parameters related to ports,
stations, virtual routing nodes, topology, directory,
intermediate sessions

o Historical information about link station errors
connection establishment, or that caused the connection
terminate

o Deactivating intermediate sessions

o Traps for SNA Management Services (SNA/MS) Alert conditions

This MIB module does not support

o Configuration of APPN nodes

o Monitoring and control of endpoint sessions

o Dependent LU Requester (DLUR) management

o High-Performance Routing (HPR) management

3.1. Relationship with RFC 2155

This MIB obsoletes RFC 2155 [29] with changes due to additions to
APPN architecture and some implementation experience of RFC 2155.
The changes from RFC 2155 are as follows

o New objects for the multi-link TG architecture enhancement
appnLsMltgMember, appnNnTgFRMltgLinkType
appnLocalTgMltgLinkType, and appnLocalEnTgMltgLinkType

o New objects, and explanations for values for existing objects
for the branch network node architecture enhancement
appnNodeBrNn, appnNnNodeFRBranchAwareness, appnNnTgFRBranchTg
and appnLocalTgBranchLinkType

o New object, appnNodeLsCounterType, to indicate which type of
traffic is returned in the appnLsTable traffic counters

o Deprecated appnNodeMibVersion object

o Miscellaneous editorial changes








Clouston & Moore Standards Track [Page 6]

RFC 2455 APPN MIB November 1998


3.2. APPN MIB

The APPN MIB module contains the following groups of objects

o appnNode - objects related to the APPN node for all node types

o appnNn - objects to represent the network nodes,
routing nodes, and TGs between these nodes that make up the
network topology database maintained in NNs

o appnLocalTopology - objects to represent nodes and TGs
nodes in the local topology database maintained in all nodes

o appnDir - objects related to LU location information from
node's directory database

o appnCos - objects related to classes of service information

o appnSessIntermediate - objects related to intermediate
that pass through this node

These groups are described below in more detail

3.2.1. appnNode

The appnNode group consists of the following tables and objects

1)

This group of objects describes general information about the
node. The type of information includes the node type and the
since this node was initialized

2)

This group of objects describes information specific to network
such as node routing characteristics

3)

This group of objects describes information specific to end nodes
with two objects that also apply to branch network nodes. This
includes an object indicating the node's network node server








Clouston & Moore Standards Track [Page 7]

RFC 2455 APPN MIB November 1998


4)

This includes the appnPortTable, which describes the
and current status of the ports used by APPN, including the
state and DLC type

5)

This includes the appnNodeLsTable, which describes the
and current status of the link stations used by APPN, including
link state and port name; and the appnLsStatusTable, which
information about errors this node encountered with connections
adjacent nodes, such as the sense data captured during
failures. It is a product option to decide how
appnLsStatusTable entries are kept

6)

This includes the appnVrnTable, which describes the
between virtual routing nodes' TGs described in the
with ports in the appnPortTable

3.2.2. appnNn

The appnNn group consists of the following objects and

1)

These objects contain general information about the network
database including the number of nodes present, and the number
topology database updates (TDU) wars the node has detected

2)

This includes tables representing the APPN network topology database
This includes the network nodes, virtual routing nodes, and
between these nodes, as well as the information about these
carried in topology updates. The tables are first indexed by
same flow reduction sequence number (FRSN) used in topology
between NNs. This allows a management station to retrieve
incremental updates, since the agent will update the FRSN of new
changed resources

3.2.3. appnLocalTopology

The appnLocalTopology group consists of the following objects
tables




Clouston & Moore Standards Track [Page 8]

RFC 2455 APPN MIB November 1998


1)

a)

Contains the local node and type

b)

These objects contain routing information about the local
node

c)

This table represents information about this node's local TGs

2)

This table represents TG information for EN TGs learned by the NN
TG registration with the local node

3.2.4. appnDir

The appnDir group consists of the following objects and tables

1)

These objects represent information related to information about
directory database and directory searches involving this node

2)

This table represents the directory database, listing LUs known
this node, along with the owning node of the LU and the serving NN
the owning node

3.2.5. appnCos

The appnCos group consists of the following tables

1)

This table represents the mode to class of service mapping

2)

This table represents the tranmission priority for each class
service




Clouston & Moore Standards Track [Page 9]

RFC 2455 APPN MIB November 1998


3)

This table represents the node-row information for each class
service, including the weight of each node

3)

This table represents the TG-row information for each class
service, including the weight of each TG

3.2.6. appnSessIntermediate

The appnSessIntermediate group consists of the following objects
tables

1)

These objects allow control of the collection of intermediate
information such as Route Selection Control Vectors (RSCVs)
counters

2)

This table contains information on active intermediate sessions

3)

This table contains information on active intermediate sessions
are being transported on Rapid Transport Protocol (RTP)
by High Performance Routing (HPR).

3.2.7.

One APPN trap is defined. It is intended to correspond to SNA/
Alerts, but is optional for a product to implement this trap.
trap identifies the Alert ID number and, where possible, the
resource

4.

APPN-MIB DEFINITIONS ::=




FROM IANAifType-

DisplayString, VariablePointer, RowPointer, DateAndTime



Clouston & Moore Standards Track [Page 10]

RFC 2455 APPN MIB November 1998


TruthValue, TimeStamp, TEXTUAL-
FROM SNMPv2-

Counter32, Gauge32, Unsigned32, TimeTicks
OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-
FROM SNMPv2-

MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-
FROM SNMPv2-


FROM SNA-NAU-MIB

appnMIB MODULE-
LAST-UPDATED "9807151800Z" -- July 15, 1998
ORGANIZATION "IETF SNA NAU MIB WG / AIW APPN MIBs SIG
CONTACT-

"

Bob
Cisco
7025 Kit Creek
P.O. Box 14987
Research Triangle Park, NC 27709,
Tel: 1 919 472 2333
E-mail: clouston@cisco.

Bob
IBM
4205 S. Miami
BRQA/501
P.O. Box 12195
Research Triangle Park, NC 27709,
Tel: 1 919 254 4436
E-mail: remoore@us.ibm.

"

"This is the MIB module for objects used
manage network devices with APPN capabilities."

-- Revision tracking starts with Proposed Standard (RFC 2155)
REVISION "9807151800Z

"Minor editorial fixes; new value 'none(5)'
to the enumeration for the
object."



Clouston & Moore Standards Track [Page 11]

RFC 2455 APPN MIB November 1998


REVISION "9805261800Z

"Post-RFC 2155 conformance definitions added
appnNodeLsCounterType and appnNodeBrNn
added, appnNodeMibVersion object deprecated."

REVISION "9707311800Z

"Branch network node (Branch Extender) objects added."
REVISION "9703311800Z

"MLTG objects added."
REVISION "9703201200Z

"RFC 2155 (Proposed Standard)"

::= { snanauMIB 4 }
-- snanauMIB ::= { mib-2 34 }

-- *********************************************************************
-- Textual
-- *********************************************************************
SnaNodeIdentification ::= TEXTUAL-
STATUS

"An SNA Node Identification consists of two parts,
together comprise four bytes of hexadecimal data. In SNA
Node Identification is transported in bytes 2-5 of the XID

The block number is the first three digits of the
Identification. These 3 hexadecimal digits identify
product

The ID number is the last 5 digits of the Node Identification
These 5 hexadecimal digits are administratively defined
combined with the 3-digit block number form the 8-digit
Identification. A unique value is required for connections
SNA subarea. In some implementations, the value 'bbb00000'
(where 'bbb' represents a 3-digit block number) is returned
mean that the ID number is not unique on this node

An SNA Node Identification is represented as
ASCII-encoded hexadecimal digits, using the characters '0' -
'9' and 'A' - 'F'."

SYNTAX OCTET STRING (SIZE (8))

SnaControlPointName ::= TEXTUAL-



Clouston & Moore Standards Track [Page 12]

RFC 2455 APPN MIB November 1998


STATUS

"A fully qualified SNA control point name, consisting of a 1
8 character network identifier (NetId), a period ('.'), and a 1
to 8 character control point name (CpName).

The NetId and CpName are constructed from the uppercase
'A' - 'Z' and the numerics '0' - '9', all encoded in ASCII
with the restriction that the first character of each must
a letter. Trailing blanks are not allowed

Earlier versions of SNA permitted three additional
in NetIds and CpNames: '#', '@', and '$'. While this use
these characters has been retired, a Management Station
still accept them for backward compatibility."

SYNTAX OCTET STRING (SIZE (3..17))

SnaClassOfServiceName ::= TEXTUAL-
STATUS

"An SNA class-of-service (COS) name, ranging from 1 to 8
ASCII characters. COS names take one of two forms

- a user-defined COS name is constructed from the
letters 'A' - 'Z' and the numerics '0' - '9', with
restriction that the first character of the name must
a letter
- an SNA-defined user-session COS name begins with
character '#', which is followed by up to
additional characters from the set of uppercase
and numerics

Trailing blanks are not allowed in either form of COS name

A zero-length string indicates that a COS name is
available."

SYNTAX OCTET STRING (SIZE (0..8))

SnaModeName ::= TEXTUAL-
STATUS

"An SNA mode name, ranging from 1 to 8 ASCII characters
Mode names take one of two forms

- a user-defined mode name is constructed from
uppercase letters 'A' - 'Z' and the numerics '0' - '9',



Clouston & Moore Standards Track [Page 13]

RFC 2455 APPN MIB November 1998


with the restriction that the first character of the
must be a letter
- an SNA-defined user-session mode name begins with
character '#', which is followed by up to
additional characters from the set of uppercase
and numerics

Trailing blanks are not allowed in either form of mode name
with the single exception of the all-blank mode name,
a string consisting of 8 blanks is returned

A zero-length string indicates that a mode name is
available."

SYNTAX OCTET STRING (SIZE (0..8))

SnaSenseData ::= TEXTUAL-
STATUS

"To facilitate their display by a Management Station,
data objects in the MIB are represented as OCTET
containing eight ASCII characters. Eight '0'
indicates that no sense data identifying an SNA
condition is available

An SNA sense data is represented as eight hexadecimal digits
using the characters '0' - '9' and 'A' - 'F'."

SYNTAX OCTET STRING (SIZE (8))

DisplayableDlcAddress ::= TEXTUAL-
STATUS

"DLC address of a port or link station, represented as
OCTET STRING containing 0 to 64 ASCII characters
A Management Station should use a value of this type
for display. The 'real' DLC address, i.e., the sequence
bytes that flow in the DLC header, is often available in
DLC-specific MIB

The zero-length string indicates that the DLC address
question is not known to the agent."

SYNTAX OCTET STRING (SIZE (0..64))

AppnNodeCounter ::= TEXTUAL-
STATUS




Clouston & Moore Standards Track [Page 14]

RFC 2455 APPN MIB November 1998


"An object providing global statistics for the entire
node. A Management Station can detect discontinuities in
counter by monitoring the appnNodeCounterDisconTime object."

SYNTAX Counter32

AppnPortCounter ::= TEXTUAL-
STATUS

"An object providing statistics for an APPN port.
Management Station can detect discontinuities in this
by monitoring the appnPortCounterDisconTime object."

SYNTAX Counter32

AppnLinkStationCounter ::= TEXTUAL-
STATUS

"An object providing statistics for an APPN link station.
Management Station can detect discontinuities in this
by monitoring the appnLsCounterDisconTime object."

SYNTAX Counter32

AppnTopologyEntryTimeLeft ::= TEXTUAL-
STATUS

"Number of days before deletion of this entry from the
database. Range is 0-15. A value of 0 indicates that
entry is either in the process of being deleted, or is
marked for deletion at the next garbage collection cycle."

SYNTAX INTEGER (0..15)

AppnTgDlcData ::= TEXTUAL-
STATUS

"DLC-specific data related to a connection network
group. For other TGs, a zero-length string is returned

Examples of the type of data returned by an object with
syntax include the following

Token-Ring - MAC/
X.25 Switched - dial
X.21 Switched - dial
Circuit Switch - dial




Clouston & Moore Standards Track [Page 15]

RFC 2455 APPN MIB November 1998


This MIB does not specify formats for these or any other
of DLC-specific data. Formats may, however, be specified
documents related to a particular DLC

The contents of an object with this syntax correspond to
contents of the DLC-specific subfields of cv46, documented
(6)."

SYNTAX OCTET STRING (SIZE (0..64))

AppnTgEffectiveCapacity ::= TEXTUAL-
STATUS

"A value representing the effective capacity of a
group. This is an administratively assigned value derived
the link bandwidth and maximum load factor. It is encoded
the same way as byte 7 of cv47, and represents a floating-
number in units of 300 bits per second."

SYNTAX OCTET STRING (SIZE (1))

AppnTgSecurity ::= TEXTUAL-
STATUS

"A value representing the level of security on a
group. A class of service definition includes an indication
the acceptable TG security value(s) for that class of service

The following seven values are defined

nonsecure(1) -
(X'01'): none of the values listed below
for example, satellite-connected
located in a nonsecure
publicSwitchedNetwork(32) -
(X'20'): public switched network;
in the sense that there is
predetermined route that traffic will
undergroundCable(64) -
(X'40'): underground cable; located in
secure country (as determined by
network administrator
secureConduit(96) -
(X'60'): secure conduit, not guarded;
example, pressurized
guardedConduit(128) -
(X'80'): guarded conduit;
against physical



Clouston & Moore Standards Track [Page 16]

RFC 2455 APPN MIB November 1998


encrypted(160) -
(X'A0'): link-level encryption is
guardedRadiation(192) -
(X'C0'): guarded conduit containing
transmission medium; protected
physical and radiation tapping

SYNTAX INTEGER {
nonsecure(1), -- X'01'
publicSwitchedNetwork(32), -- X'20'
undergroundCable(64), -- X'40'
secureConduit(96), -- X'60'
guardedConduit(128), -- X'80'
encrypted(160), -- X'A0'
guardedRadiation(192) -- X'C0'
}

AppnTgDelay ::= TEXTUAL-
STATUS

"Relative amount of time that it takes for a signal to
the length of a logical link. This time is represented
microseconds, using the same encoding scheme used in cv47 in
topology update. Some of the more common values, along
their encoded hex values, are

minimum(0), X'00'
negligible(384), X'4C
terrestrial(9216), X'71'
packet(147456), X'91'
long(294912), X'99'
maximum(2013265920) X'FF

"

SYNTAX OCTET STRING (SIZE (1))

-- *********************************************************************
appnObjects OBJECT IDENTIFIER ::= { appnMIB 1 }
-- *********************************************************************

-- ******************** The APPN Node Group ****************************

appnNode OBJECT IDENTIFIER ::= { appnObjects 1 }
appnGeneralInfoAndCaps OBJECT IDENTIFIER ::= { appnNode 1 }
appnNnUniqueInfoAndCaps OBJECT IDENTIFIER ::= { appnNode 2 }
appnEnUniqueCaps OBJECT IDENTIFIER ::= { appnNode 3 }
appnPortInformation OBJECT IDENTIFIER ::= { appnNode 4 }



Clouston & Moore Standards Track [Page 17]

RFC 2455 APPN MIB November 1998


appnLinkStationInformation OBJECT IDENTIFIER ::= { appnNode 5 }
appnVrnInfo OBJECT IDENTIFIER ::= { appnNode 6 }

-- This group provides global information about an APPN network node
-- an APPN end node, an APPN branch network node, or an LEN node

-- APPN General
-- This section applies to APPN network nodes, end nodes, and
-- network nodes, as well as to LEN end nodes

appnNodeCpName OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Administratively assigned network name for this node."

::= { appnGeneralInfoAndCaps 1 }

-- appnNodeMibVersion OBJECT-TYPE (deprecated: moved to end of module

appnNodeId OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"This node's Node Identification, which it sends in
2-5 of XID."

::= { appnGeneralInfoAndCaps 3 }

appnNodeType OBJECT-
SYNTAX INTEGER {
networkNode(1),
endNode(2),
t21len(4)
}
MAX-ACCESS read-
STATUS

"Type of APPN node

networkNode(1) - APPN network
endNode(2) - APPN end
t21len(4) - LEN end

Note: A branch network node SHALL return endNode(2)
as the value of this object. A management



Clouston & Moore Standards Track [Page 18]

RFC 2455 APPN MIB November 1998


can distinguish between a branch network node and
actual end node by retrieving the appnNodeBrNn object."

::= { appnGeneralInfoAndCaps 4 }

appnNodeUpTime OBJECT-
SYNTAX
UNITS "hundredths of a second
MAX-ACCESS read-
STATUS

"Amount of time (in hundredths of a second) since the APPN
was last reinitialized."

::= { appnGeneralInfoAndCaps 5 }

appnNodeParallelTg OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether this node supports parallel TGs."

::= { appnGeneralInfoAndCaps 6 }

appnNodeAdaptiveBindPacing OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether this node supports adaptive bind pacing
dependent LUs."

::= { appnGeneralInfoAndCaps 7 }

appnNodeHprSupport OBJECT-
SYNTAX INTEGER {
noHprSupport(1),
hprBaseOnly(2),
rtpTower(3),
controlFlowsOverRtpTower(4)
}
MAX-ACCESS read-
STATUS

"Indicates this node's level of support for high-
routing (HPR):




Clouston & Moore Standards Track [Page 19]

RFC 2455 APPN MIB November 1998


noHprSupport(1) - no HPR
hprBaseOnly(2) - HPR base (option set 1400)

rtpTower(3) - HPR base and RTP
(option set 1401)
controlFlowsOverRtpTower(4) - HPR base, RTP tower,
control flows over
(option set 1402)

This object corresponds to cv4580, byte 9, bits 3-4."

::= { appnGeneralInfoAndCaps 8 }

appnNodeMaxSessPerRtpConn OBJECT-
SYNTAX Gauge32
MAX-ACCESS read-
STATUS

"This object represents a configuration parameter
the maximum number of sessions that the APPN node is to put
any HPR connection. The value is zero if not applicable."

::= { appnGeneralInfoAndCaps 9 }

appnNodeHprIntRteSetups OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"The total number of HPR route setups received for
passing through this node since the node was
reinitialized."

::= { appnGeneralInfoAndCaps 10 }

appnNodeHprIntRteRejects OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"The number of HPR route setups rejected by this node
routes passing through it since the node was
reinitialized."

::= { appnGeneralInfoAndCaps 11 }

appnNodeHprOrgRteSetups OBJECT-
SYNTAX



Clouston & Moore Standards Track [Page 20]

RFC 2455 APPN MIB November 1998


MAX-ACCESS read-
STATUS

"The total number of HPR route setups sent for
originating in this node since the node was
reinitialized."

::= { appnGeneralInfoAndCaps 12 }

appnNodeHprOrgRteRejects OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"The number of HPR route setups rejected by other nodes
routes originating in this node since the node was
reinitialized."

::= { appnGeneralInfoAndCaps 13 }

appnNodeHprEndRteSetups OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"The total number of HPR route setups received for
ending in this node since the node was last reinitialized."

::= { appnGeneralInfoAndCaps 14 }

appnNodeHprEndRteRejects OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"The number of HPR route setups rejected by this node
routes ending in it since the node was last reinitialized."

::= { appnGeneralInfoAndCaps 15 }

appnNodeCounterDisconTime OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"The value of the sysUpTime object the last time the APPN
was reinitialized."




Clouston & Moore Standards Track [Page 21]

RFC 2455 APPN MIB November 1998


::= { appnGeneralInfoAndCaps 16 }

appnNodeLsCounterType OBJECT-
SYNTAX INTEGER {
other(1),
noAnr(2),
anrForLocalNces(3),
allAnr(4)
}
MAX-ACCESS read-
STATUS

"Indicates which ANR traffic, if any, the node includes in
counts returned by the APPN link station
appnLsInXidBytes, appnLsInMsgBytes, appnLsInXidFrames
appnLsInMsgFrames, appnLsOutXidBytes, appnLsOutMsgBytes
appnLsOutXidFrames, and appnLsOutMsgFrames. These
are always incremented for ISR traffic

The following values are defined

other(1) - the node does something
from all the options listed
noAnr(2) - the node does not include any
traffic in these
anrForLocalNces(3) - the node includes in these
ANR traffic for RTP
that terminate in this node,
not ANR traffic for RTP
that pass through this node
terminating in
allAnr(4) - the node includes all ANR
in these counts."

::= { appnGeneralInfoAndCaps 17 }

appnNodeBrNn OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether this node is currently configured as
branch network node

Note: throughout the remainder of this MIB module,
network node is treated as a third node type, parallel
network node and end node. This is not how branch
nodes are treated in the base APPN architecture, but



Clouston & Moore Standards Track [Page 22]

RFC 2455 APPN MIB November 1998


increases clarity to do it here."

::= { appnGeneralInfoAndCaps 18 }

-- *********************************************************************
-- APPN Network Node
-- This section provides global information about an APPN network node
-- *********************************************************************

appnNodeNnCentralDirectory OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether this node supports central
services

This object corresponds to cv4580, byte 8, bit 1."

::= { appnNnUniqueInfoAndCaps 1 }

appnNodeNnTreeCache OBJECT-
SYNTAX INTEGER {
noCache(1),
cacheNoIncrUpdate(2),
cacheWithIncrUpdate(3)
}
MAX-ACCESS read-
STATUS

"Indicates this node's level of support for caching of
trees. Three levels are specified

noCache(1) - caching of route trees is

cacheNoIncrUpdate(2) - caching of route trees
supported, but without

cacheWithIncrUpdate(3) - caching of route trees
incremental updates is supported

::= { appnNnUniqueInfoAndCaps 2 }

appnNodeNnRouteAddResist OBJECT-
SYNTAX INTEGER (0..255)
MAX-ACCESS read-
STATUS




Clouston & Moore Standards Track [Page 23]

RFC 2455 APPN MIB November 1998


"Route addition resistance

This administratively assigned value indicates the
desirability of using this node for intermediate
traffic. The value, which can be any integer 0-255, is
in route computation. The lower the value, the
desirable the node is for intermediate routing

This object corresponds to cv4580, byte 6."

::= { appnNnUniqueInfoAndCaps 3 }

appnNodeNnIsr OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether the node supports intermediate
routing

This object corresponds to cv4580, byte 8, bit 2."

::= { appnNnUniqueInfoAndCaps 4 }

appnNodeNnFrsn OBJECT-
SYNTAX Unsigned32
MAX-ACCESS read-
STATUS

"The last flow-reduction sequence number (FRSN) sent by
node in a topology update to an adjacent network node."

::= { appnNnUniqueInfoAndCaps 5 }

appnNodeNnPeriBorderSup OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether this node has peripheral border
support

This object corresponds to cv4580, byte 9, bit 0."

::= { appnNnUniqueInfoAndCaps 6 }

appnNodeNnInterchangeSup OBJECT-
SYNTAX



Clouston & Moore Standards Track [Page 24]

RFC 2455 APPN MIB November 1998


MAX-ACCESS read-
STATUS

"Indicates whether this node has interchange node support

This object corresponds to cv4580, byte 9, bit 1."

::= { appnNnUniqueInfoAndCaps 7 }

appnNodeNnExteBorderSup OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether this node has extended border node support

This object corresponds to cv4580, byte 9, bit 2."

::= { appnNnUniqueInfoAndCaps 8 }


appnNodeNnSafeStoreFreq OBJECT-
SYNTAX INTEGER (0..32767)
UNITS "TDUs
MAX-ACCESS read-
STATUS

"The topology safe store frequency

If this number is not zero, then the topology database is
each time the total number of topology database updates (TDUs
received by this node increases by this number. A value
zero indicates that the topology database is not being saved."

::= { appnNnUniqueInfoAndCaps 9 }

appnNodeNnRsn OBJECT-
SYNTAX Unsigned32
MAX-ACCESS read-
STATUS

"Resource sequence number for this node, which it assigns
controls

This object corresponds to the numeric value in cv4580,
2-5."

::= { appnNnUniqueInfoAndCaps 10 }



Clouston & Moore Standards Track [Page 25]

RFC 2455 APPN MIB November 1998


appnNodeNnCongested OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether this node is congested. Other network
stop routing traffic to this node while this flag is on

This object corresponds to cv4580, byte 7, bit 0."
::= { appnNnUniqueInfoAndCaps 11 }

appnNodeNnIsrDepleted OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicate whether intermediated session routing resources
depleted. Other network nodes stop routing traffic
this node while this flag is on

This object corresponds to cv4580, byte 7, bit 1."

::= { appnNnUniqueInfoAndCaps 12 }

appnNodeNnQuiescing OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether the node is quiescing

This object corresponds to cv4580, byte 7, bit 5."

::= { appnNnUniqueInfoAndCaps 13 }

appnNodeNnGateway OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether the node has gateway services support

This object corresponds to cv4580, byte 8, bit 0."

::= { appnNnUniqueInfoAndCaps 14 }


-- *********************************************************************



Clouston & Moore Standards Track [Page 26]

RFC 2455 APPN MIB November 1998


-- APPN End Node
-- This section provides global information about an APPN end node.
-- of the objects are also implemented by a branch network node
-- *********************************************************************

appnNodeEnModeCosMap OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether this end node supports mode name to COS
mapping."

::= { appnEnUniqueCaps 1 }

appnNodeEnNnServer OBJECT-
SYNTAX OCTET STRING (SIZE (0 | 3..17))
MAX-ACCESS read-
STATUS

"The fully qualified name of the current NN server for this
node. An NN server is identified using the format specified
the SnaControlPointName textual convention. The value is
zero-length string when there is no active NN server

A branch network node shall also implement this object."

::= { appnEnUniqueCaps 2 }

appnNodeEnLuSearch OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether the node is to be searched for LUs as
of a network broadcast search

A branch network node shall also implement this object."

::= { appnEnUniqueCaps 3 }


-- *********************************************************************
-- APPN Port
-- This section provides information about an APPN node's ports
-- *********************************************************************





Clouston & Moore Standards Track [Page 27]

RFC 2455 APPN MIB November 1998


appnPortTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS

"The Port table describes the configuration and current
of the ports used by APPN. When it is known to the
component, an OBJECT IDENTIFIER pointing to
information related to the port is included. This may,
need not, be a RowPointer to an ifTable entry for a
interface immediately 'below' the port."

::= { appnPortInformation 1 }

appnPortEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS

"The port name is used as the index to this table."


{ appnPortName }

::= { appnPortTable 1 }

AppnPortEntry ::= SEQUENCE {
appnPortName DisplayString
appnPortCommand INTEGER
appnPortOperState INTEGER
appnPortDlcType IANAifType
appnPortPortType INTEGER
appnPortSIMRIM TruthValue
appnPortLsRole INTEGER
appnPortNegotLs TruthValue
appnPortDynamicLinkSupport TruthValue
appnPortMaxRcvBtuSize INTEGER
appnPortMaxIframeWindow Gauge32,
appnPortDefLsGoodXids AppnPortCounter
appnPortDefLsBadXids AppnPortCounter
appnPortDynLsGoodXids AppnPortCounter
appnPortDynLsBadXids AppnPortCounter
appnPortSpecific RowPointer
appnPortDlcLocalAddr DisplayableDlcAddress
appnPortCounterDisconTime
}

appnPortName OBJECT-



Clouston & Moore Standards Track [Page 28]

RFC 2455 APPN MIB November 1998


SYNTAX DisplayString (SIZE (1..10))
MAX-ACCESS not-
STATUS


"Administratively assigned name for this APPN port."

::= { appnPortEntry 1 }

appnPortCommand OBJECT-
SYNTAX INTEGER {
deactivate(1),
activate(2),
recycle(3),
ready(4)
}
MAX-ACCESS read-
STATUS

"Object by which a Management Station can activate, deactivate
or recycle (i.e., cause to be deactivated and then
activated) a port, by setting the value to activate(1),
deactivate(2), or recycle(3), respectively. The value ready(4)
is returned on GET operations until a SET has been processed
after that the value received on the most recent SET
returned."

::= { appnPortEntry 2 }

appnPortOperState OBJECT-
SYNTAX INTEGER {
inactive(1),
pendactive(2),
active(3),
pendinact(4)
}
MAX-ACCESS read-
STATUS

"Indicates the current state of this port

inactive(1) - port is
pendactive(2) - port is pending
active(3) - port is
pendinact(4) - port is pending inactive


::= { appnPortEntry 3 }



Clouston & Moore Standards Track [Page 29]

RFC 2455 APPN MIB November 1998


appnPortDlcType OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"The type of DLC interface, distinguished according to
protocol immediately 'below' this layer."

::= { appnPortEntry 4 }

appnPortPortType OBJECT-
SYNTAX INTEGER {
leased(1),
switched(2),
sharedAccessFacilities(3)
}
MAX-ACCESS read-
STATUS

"Identifies the type of line used by this port

leased(1) - leased
switched(2) - switched
sharedAccessFacilities(3) - shared access facility,
as a LAN."

::= { appnPortEntry 5 }

appnPortSIMRIM OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether Set Initialization Mode (SIM) and
Initialization Mode (RIM) are supported for this port."

::= { appnPortEntry 6 }

appnPortLsRole OBJECT-
SYNTAX INTEGER {
primary(1),
secondary(2),
negotiable(3),
abm(4)
}
MAX-ACCESS read-
STATUS




Clouston & Moore Standards Track [Page 30]

RFC 2455 APPN MIB November 1998


"Initial role for link stations activated through this port
The values map to the following settings in the initial XID
where 'ABM' indicates asynchronous balanced mode and 'NRM
indicated normal response mode

primary(1): ABM support = 0 ( = NRM
role = 01 ( = primary
secondary(2): ABM support = 0 ( = NRM
role = 00 ( = secondary
negotiable(3): ABM support = 0 ( = NRM
role = 11 ( = negotiable
abm(4): ABM support = 1 ( = ABM
role = 11 ( = negotiable)"

::= { appnPortEntry 7 }

appnPortNegotLs OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether the node supports negotiable link
for this port."

::= { appnPortEntry 8 }

appnPortDynamicLinkSupport OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether this node allows call-in on this port
nodes not defined locally."

::= { appnPortEntry 9 }

appnPortMaxRcvBtuSize OBJECT-
SYNTAX INTEGER (99..32767)
UNITS "bytes
MAX-ACCESS read-
STATUS

"Maximum Basic Transmission Unit (BTU) size that a link
on this port can receive

This object corresponds to bytes 21-22 of XID3."

::= { appnPortEntry 10 }



Clouston & Moore Standards Track [Page 31]

RFC 2455 APPN MIB November 1998


appnPortMaxIframeWindow OBJECT-
SYNTAX Gauge32
UNITS "I-frames
MAX-ACCESS read-
STATUS

"Maximum number of I-frames that can be received by the
sender before an acknowledgement is received."

::= { appnPortEntry 11 }

appnPortDefLsGoodXids OBJECT-
SYNTAX
UNITS "XID exchanges
MAX-ACCESS read-
STATUS

"The total number of successful XID exchanges that
occurred on all defined link stations on this port since
last time this port was started."

::= { appnPortEntry 12 }

appnPortDefLsBadXids OBJECT-
SYNTAX
UNITS "XID exchanges
MAX-ACCESS read-
STATUS

"The total number of unsuccessful XID exchanges that
occurred on all defined link stations on this port since
last time this port was started."

::= { appnPortEntry 13 }

appnPortDynLsGoodXids OBJECT-
SYNTAX
UNITS "XID exchanges
MAX-ACCESS read-
STATUS

"The total number of successful XID exchanges that
occurred on all dynamic link stations on this port since
last time this port was started."

::= { appnPortEntry 14 }

appnPortDynLsBadXids OBJECT-



Clouston & Moore Standards Track [Page 32]

RFC 2455 APPN MIB November 1998


SYNTAX
UNITS "XID exchanges
MAX-ACCESS read-
STATUS

"The total number of unsuccessful XID exchanges that
occurred on all dynamic link stations on this port since
last time this port was started."

::= { appnPortEntry 15 }

appnPortSpecific OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Identifies the object, e.g., one in a DLC-specific MIB,
can provide additional information related to this port

If the agent is unable to identify such an object, the
0.0 is returned."

::= { appnPortEntry 16 }

appnPortDlcLocalAddr OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Local DLC address of this port."

::= { appnPortEntry 17 }

appnPortCounterDisconTime OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"The value of the sysUpTime object the last time the port
started."

::= { appnPortEntry 18 }

-- *********************************************************************
-- APPN Link Station
-- This section provides information about an APPN node's link stations
-- *********************************************************************




Clouston & Moore Standards Track [Page 33]

RFC 2455 APPN MIB November 1998


appnLsTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS

"This table contains detailed information about the
station configuration and its current status."

::= { appnLinkStationInformation 1 }

appnLsEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS

"This table is indexed by the link station name."


{ appnLsName }

::= { appnLsTable 1 }

AppnLsEntry ::= SEQUENCE {
appnLsName DisplayString
appnLsCommand INTEGER
appnLsOperState INTEGER

appnLsPortName DisplayString
appnLsDlcType IANAifType
appnLsDynamic TruthValue

appnLsAdjCpName OCTET STRING
appnLsAdjNodeType INTEGER
appnLsTgNum INTEGER
appnLsLimResource TruthValue
appnLsActOnDemand TruthValue
appnLsMigration TruthValue
appnLsPartnerNodeId SnaNodeIdentification
appnLsCpCpSessionSupport TruthValue

appnLsMaxSendBtuSize INTEGER
-- performance
appnLsInXidBytes AppnLinkStationCounter
appnLsInMsgBytes AppnLinkStationCounter
appnLsInXidFrames AppnLinkStationCounter
appnLsInMsgFrames AppnLinkStationCounter
appnLsOutXidBytes AppnLinkStationCounter
appnLsOutMsgBytes AppnLinkStationCounter



Clouston & Moore Standards Track [Page 34]

RFC 2455 APPN MIB November 1998


appnLsOutXidFrames AppnLinkStationCounter
appnLsOutMsgFrames AppnLinkStationCounter
-- propagation
appnLsEchoRsps AppnLinkStationCounter
appnLsCurrentDelay Gauge32,
appnLsMaxDelay Gauge32,
appnLsMinDelay Gauge32,
appnLsMaxDelayTime DateAndTime
-- XID
appnLsGoodXids AppnLinkStationCounter
appnLsBadXids AppnLinkStationCounter
-- DLC-
appnLsSpecific RowPointer
appnLsActiveTime Unsigned32,
appnLsCurrentStateTime TimeTicks
-- HPR-
appnLsHprSup INTEGER
appnLsErrRecoSup TruthValue
appnLsForAnrLabel OCTET STRING
appnLsRevAnrLabel OCTET STRING
appnLsCpCpNceId OCTET STRING
appnLsRouteNceId OCTET STRING
appnLsBfNceId OCTET STRING

appnLsLocalAddr DisplayableDlcAddress
appnLsRemoteAddr DisplayableDlcAddress
appnLsRemoteLsName DisplayString
appnLsCounterDisconTime TimeStamp
appnLsMltgMember
}

appnLsName OBJECT-
SYNTAX DisplayString (SIZE (1..10))
MAX-ACCESS not-
STATUS

"Administratively assigned name for the link station
The name can be from one to ten characters."

::= { appnLsEntry 1 }

appnLsCommand OBJECT-
SYNTAX INTEGER {
deactivate(1),
activate(2),
recycle(3),
ready(4)
}



Clouston & Moore Standards Track [Page 35]

RFC 2455 APPN MIB November 1998


MAX-ACCESS read-
STATUS

"Object by which a Management Station can activate, deactivate
or recycle (i.e., cause to be deactivated and then
reactivated) a link station, by setting the value
activate(1), deactivate(2), or recycle(3), respectively.
value ready(4) is returned on GET operations until a SET
been processed; after that the value received on the
recent SET is returned."

::= { appnLsEntry 2 }

appnLsOperState OBJECT-
SYNTAX INTEGER {
inactive(1),
sentConnectOut(2), -- pending
pendXidExch(3), -- pending
sendActAs(4), -- pending
sendSetMode(5), -- pending
otherPendingActive(6),-- pending
active(7),
sentDeactAsOrd(8), -- pending
sentDiscOrd(9), -- pending
sentDiscImmed(10), -- pending
otherPendingInact(11) -- pending
}
MAX-ACCESS read-
STATUS

"State of this link station. The comments map these
granular states to the 'traditional' four states for
resources. Values (2) through (5) represent the
progression of states when a link station is being activated
Value (6) represents some other state of a link station
the process of being activated. Values (8) through (10)
represent different ways a link station can be deactivated
Value (11) represents some other state of a link station
the process of being deactivated."

::= { appnLsEntry 3 }

appnLsPortName OBJECT-
SYNTAX DisplayString (SIZE (1..10))
MAX-ACCESS read-
STATUS

"Administratively assigned name for the port associated



Clouston & Moore Standards Track [Page 36]

RFC 2455 APPN MIB November 1998


this link station. The name can be from one to
characters."

::= { appnLsEntry 4 }

appnLsDlcType OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"The type of DLC interface, distinguished according to
protocol immediately 'below' this layer."

::= { appnLsEntry 5 }

appnLsDynamic OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Identifies whether this is a dynamic link station.
link stations are created when links that have not been
defined are established by adjacent nodes."

::= { appnLsEntry 6 }

appnLsAdjCpName OBJECT-
SYNTAX OCTET STRING (SIZE (0 | 3..17))
MAX-ACCESS read-
STATUS

"Fully qualified name of the adjacent node for this
station. An adjacent node is identified using the
specified in the SnaControlPointName textual convention

The value of this object is determined as follows

1. If the adjacent node's name was received on XID,
is returned

2. If the adjacent node's name was not received on XID
but a locally-defined value is available, it
returned

3. Otherwise a string of length 0 is returned,
that no name is known for the adjacent node."

::= { appnLsEntry 7 }



Clouston & Moore Standards Track [Page 37]

RFC 2455 APPN MIB November 1998


appnLsAdjNodeType OBJECT-
SYNTAX INTEGER {
networkNode(1),
endNode(2),
t21len(4),
unknown(255)
}
MAX-ACCESS read-
STATUS

"Node type of the adjacent node on this link

networkNode(1) - APPN network
endNode(2) - APPN end
t21len(4) - LEN end
unknown(255) - the agent does not know the node
of the adjacent
"

::= { appnLsEntry 8 }

appnLsTgNum OBJECT-
SYNTAX INTEGER (0..256)
MAX-ACCESS read-
STATUS

"Number associated with the TG to this link station, with
range from 0 to 256. A value of 256 indicates that the
number has not been negotiated and is unknown at this time."

::= { appnLsEntry 9 }

appnLsLimResource OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether the link station is a limited resource.
link station that is a limited resource is deactivated when
is no longer in use."

::= { appnLsEntry 10 }

appnLsActOnDemand OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS




Clouston & Moore Standards Track [Page 38]

RFC 2455 APPN MIB November 1998


"Indicates whether the link station is activatable on demand

Such a link station is reported in the topology as
regardless of its actual state, so that it can be considered
route calculations. If the link station is inactive and
chosen for a route, it will be activated at that time."

::= { appnLsEntry 11 }

appnLsMigration OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether this link station will be used
connections to down-level or migration partners

In general, migration nodes do not append their CP names
XID3. Such nodes: (1) will not support parallel TGs, (2)
should be sent an ACTIVATE PHYSICAL UNIT (ACTPU), provided
the partner supports ACTPUs, and (3) should not be
segmented BINDs. However, if this node receives an XID3
an appended CP name, then the partner node will not be
as a migration node

In the case of DYNAMIC TGs this object should be set to 'no'."

::= { appnLsEntry 12 }

appnLsPartnerNodeId OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"The partner's Node Identification, from bytes 2-5 of the
received from the partner. If this value is not available
then the characters '00000000' are returned."

::= { appnLsEntry 13 }

appnLsCpCpSessionSupport OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"Indicates whether CP-CP sessions are supported by
link station. For a dynamic link, this object
the default ('Admin') value."



Clouston & Moore Standards Track [Page 39]

RFC 2455 APPN MIB November 1998


::= { appnLsEntry 14 }

appnLsMaxSendBtuSize OBJECT-
SYNTAX INTEGER (99..32767)
UNITS "bytes
MAX-ACCESS read-
STATUS

"Numeric value between 99 and 32767 inclusive indicating
maximum number of bytes in a Basic Transmission Unit (BTU)
on this link

When the link state (returned by the appnLsOperState object)
inactive or pending active, the value configured at this
is returned. When the link state is active, the value that
negotiated for it is returned. This negotiated value is
smaller of the value configured at this node and the partner'
maximum receive BTU length, received in XID."

::= { appnLsEntry 15 }

appnLsInXidBytes OBJECT-
SYNTAX
UNITS "bytes
MAX-ACCESS read-
STATUS

"Number of XID bytes received. All of the bytes in the
basic transmission unit (BTU), i.e., all of the bytes in
DLC XID Information Field, are counted."

::= { appnLsEntry 16 }

appnLsInMsgBytes OBJECT-
SYNTAX
UNITS "bytes
MAX-ACCESS read-
STATUS

"Number of message (I-frame) bytes received. All of the
in the SNA basic transmission unit (BTU), including
transmission header (TH), are counted."

::= { appnLsEntry 17 }

appnLsInXidFrames OBJECT-
SYNTAX
UNITS "XID frames



Clouston & Moore Standards Track [Page 40]

RFC 2455 APPN MIB November 1998


MAX-ACCESS read-
STATUS

"Number of XID frames received."

::= { appnLsEntry 18 }

appnLsInMsgFrames OBJECT-
SYNTAX
UNITS "I-frames
MAX-ACCESS read-
STATUS

"Number of message (I-frame) frames received."

::= { appnLsEntry 19 }

appnLsOutXidBytes OBJECT-
SYNTAX
UNITS "bytes
MAX-ACCESS read-
STATUS

"Number of XID bytes sent. All of the bytes in the SNA
transmission unit (BTU), i.e., all of the bytes in the DLC
Information Field, are counted."

::= { appnLsEntry 20 }

appnLsOutMsgBytes OBJECT-
SYNTAX
UNITS "bytes
MAX-ACCESS read-
STATUS

"Number of message (I-frame) bytes sent. All of the
in the SNA basic transmission unit (BTU), including
transmission header (TH), are counted."

::= { appnLsEntry 21 }

appnLsOutXidFrames OBJECT-
SYNTAX
UNITS "XID frames
MAX-ACCESS read-
STATUS

"Number of XID frames sent."



Clouston & Moore Standards Track [Page 41]

RFC 2455 APPN MIB November 1998


::= { appnLsEntry 22 }

appnLsOutMsgFrames OBJECT-
SYNTAX
UNITS "I-frames
MAX-ACCESS read-
STATUS

"Number of message (I-frame) frames sent."

::= { appnLsEntry 23 }

appnLsEchoRsps OBJECT-
SYNTAX
UNITS "echo responses
MAX-ACCESS read-
STATUS