Definitions of Managed Objects for Extended Border Node
RFC 2457
| Document | Type | RFC - Proposed Standard (November 1998) | |
|---|---|---|---|
| Authors | Dr. Robert C. Moore , Bob Clouston | ||
| Last updated | 2013-03-02 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | (None) | |
| Send notices to | (None) |
RFC 2457
Network Working Group B. Clouston
Request for Comments: 2457 Cisco Systems
Category: Standards Track B. Moore
IBM Corporation
November 1998
Definitions of Managed Objects
for Extended Border Node
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 (1998). All Rights Reserved.
Abstract
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 controlling
network devices with APPN (Advanced Peer-to-Peer Network) EBN
(Extended Border Node) capabilities. This memo identifies managed
objects for the EBN architecture.
Table of Contents
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2.0 The SNMP Network Management Framework . . . . . . . . . . 2
3.0 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 EBN MIB Structure . . . . . . . . . . . . . . . . . . . . 4
3.1.1 enbDir group . . . . . . . . . . . . . . . . . . . . . 5
3.1.2 ebnIsRscv group . . . . . . . . . . . . . . . . . . . 5
3.1.3 ebnDirConfig group . . . . . . . . . . . . . . . . . . 7
3.1.4 ebnCos group . . . . . . . . . . . . . . . . . . . . . 8
3.1.5 ebnSubnetRoutingList group . . . . . . . . . . . . . . 8
3.1.6 hbn group . . . . . . . . . . . . . . . . . . . . . . 8
4.0 Definitions . . . . . . . . . . . . . . . . . . . . . . . 9
5.0 Security Considerations . . . . . . . . . . . . . . . . . 24
6.0 Intellectual Property . . . . . . . . . . . . . . . . . . 25
7.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 25
8.0 References . . . . . . . . . . . . . . . . . . . . . . . . 25
Clouston & Moore Standards Track [Page 1]
RFC 2457 Extended Border Node MIB November 1998
9.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 27
10.0 Full Copyright Statement . . . . . . . . . . . . . . . . 28
1.0 Introduction
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) Extended Border Node (EBN) capabilities.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119, reference
[13].
2.0 The SNMP Network Management Framework
The SNMP Network Management Framework presently consists of six major
components. They are:
o the overall architecture, described in RFC 2271 [7].
o the SMI, described in RFC 1902 [3], - the mechanisms used for
describing and naming objects for the purpose of management.
o the MIB-II, STD 17, RFC 1213 [2], - the core set of managed
objects for the Internet suite of protocols.
o the protocol, STD 15, RFC 1157 [1] and/or RFC 1905 [6] and/or RFC
2272 [8] -- the protocol for accessing managed information.
o the user-based security model defined in RFC 2274 [10].
o the view-based access control model defined in RFC 2275 [11].
Textual conventions are defined in RFC 1903 [4], and conformance
statements are defined in RFC 1904 [5]. Common applications are
defined in RFC 2273 [9].
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
This memo specifies a MIB module that is compliant to the SMIv2. A
MIB conforming to the SMIv1 can be produced through the appropriate
translation.
Clouston & Moore Standards Track [Page 2]
RFC 2457 Extended Border Node MIB November 1998
3.0 Overview
This document identifies the proposed set of objects for monitoring
the configuration and active characteristics of devices with EBN
capabilities. The Extended Border Node function is an APPN
enhancement for an APPN network node (NN). It supports topology
isolation, subnet interconnection, and session establishment between
subnets.
In a single APPN network, all network topology information is
propagated to all network nodes. Directory searches can also be
forwarded to all network nodes. As the network grows, this network
traffic could become prohibitive. Also, in networks where different
enterprises are connected via APPN, it may be desirable to shield an
enterprise from the network traffic of another enterprise. EBNs
allow customers to partition a network into subnets to reduce or
shield such network traffic.
An EBN provides this function by blocking topology information
exchange between subnets, and controlling where directory searches
are forwarded. A subnetwork is a cluster of APPN NNs which share the
same network topology. Subnetwork boundaries, or partitions, occur
where an EBN and an NN adjacent to it have different network
identifiers (NETIDs). They may also occur where an EBN and adjacent
NN have the same NETID but are configured to have a subnetwork
boundary.
The connection between two APPN nodes is an APPN transmission group
(TG). A TG at a subnet boundary is called an Intersubnetwork
Transmission Group (ISTG).
The subnet in which an EBN resides is called its native subnetwork.
The subnet across the subnet boundary is called the non-native
subnetwork, with respect to the EBN.
A cost of the EBN function is that customers may have difficulty
determining the end-to-end route of sessions that cross subnet
boundaries, and understanding how the EBN will control directory
searches between subnets. This MIB addresses these issues.
Another challenge facing customers is to identify subnet boundaries
formed by EBNs. The SNANAU APPN MIB [14] identifies subnet
boundaries in the appnNnTopology group. The SNANAU APPN MIB provides
management of APPN objects, and contains some tables that are
extended by this MIB.
In this document, we describe EBN managed objects.
Clouston & Moore Standards Track [Page 3]
RFC 2457 Extended Border Node MIB November 1998
The EBN terms and overall architecture are available from the
networking.raleigh.ibm.com ftp site [15].
Highlights of the management functions supported by the EBN MIB
module include the following:
o Identifying the subnet affiliation of LUs (logical units)
o Identifying session routes in non-native subnets, with
correlation to the route in the native subnet provided in the
SNANAU APPN MIB.
o Identifying the COS (Class of Service) mappings between subnets.
o Identifying the subnet routing lists
This MIB module does not support:
o Configuration of EBN nodes.
o Historical information about session initiation failures.
o Peripheral Border Node (PBN) support. PBN is an APPN function
that only supports communication to adjacent subnetworks, and is
not expected to be widely implemented.
o Traps. The APPN MIB contains a trap for Alert conditions that
may affect EBN resources. Although no APPN/EBN Alerts are
defined today in the APPN MIB [14], they could exist in the
future. The value for the affectedObject object contained in the
alertTrap is determined by the implementation. It may contain a
VariablePointer from the EBN MIB.
3.1 EBN MIB Structure
The EBN MIB module contains the following groups of objects:
o ebnDir - subnet information about LUs.
o ebnIsRscv - provides the RSCV (Route Selection Control
Vector) and COS for the subnetwork on the BIND destination side
of the EBN.
o ebnDirConfig - objects related to the EBN directory.
o ebnCos - COS mapping between subnetworks,
Clouston & Moore Standards Track [Page 4]
RFC 2457 Extended Border Node MIB November 1998
o ebnSubnetRoutingList - the customer-supplied list of where to
forward search requests.
o hbn - HPR (High Performance Routing) EBN intermediate session
information.
These groups are described below in more detail.
3.1.1 enbDir group
The ebnDir group contains the ebnDirTable, which is an extension to
the appnDirTable. It specifies the subnet affiliation of LUs in the
EBN's directory.
3.1.2 ebnIsRscv group
The ebnIsRscv group contains the ebnIsRscvTable, which is an
extension to the appnIsInTable. The appnIsInTable only allows for
the RSCV and COS name for one subnetwork traversed by a session.
This extension contains the RSCV and COS name for the other
subnetwork.
When an EBN changes RSCVs before forwarding a BIND, appnIsInRouteInfo
contains the incoming RSCV, and ebnIsRscvDestinationRoute contains
the outgoing RSCV.
The following three cases illustrate the contents of
appnIsInRouteInfo and ebnIsRscvDestinationRoute at Extended Border
Nodes.
1. EBN connected to another EBN
**subnet 1**|-----ISTG ------|**subnet 2**
EBN1 EBN2
PLU SLU
---------------------------->|
(1) |--------------->|
(2) |---------->
(3)
PLU = Primary Logical Unit (session initiator)
SLU = Secondary Logical Unit (session destination)
The value of the appnIsInRouteInfo object at EBN1 is the RSCV
containing the route, represented by (1), from the PLU (or the
entry EBN in its subnet) to EBN2. The value of
ebnIsRscvDestinationRoute object at EBN1 is the RSCV, represented
by (2), containing the one-hop route from EBN1 to EBN2. The
Clouston & Moore Standards Track [Page 5]
RFC 2457 Extended Border Node MIB November 1998
appnIsInRouteInfo object at EBN2 also contains the RSCV
represented by (2). The value of ebnIsRscvDestinationRoute in
EBN2 is the RSVC containing the route to the SLU (or to the next
subnet's entry EBN), represented by (3).
2. EBN connected to a NN or PBN
**subnet 1**|-----ISTG ------|**subnet 2**
EBN1 NN/PBN
PLU SLU
---------------------------->|
(1) |--------------------------->
(2)
The value of the appnIsInRouteInfo object at EBN1 is the RSCV
containing the route from the PLU (or the entry EBN in its
subnet) to the NN or PBN, represented by (1). The value of the
ebnIsRscvDestinationRoute object at EBN1 is the RSCV containing
the route from EBN1 to the SLU, represented by (2). Note that
the SLU must be in subnet 2, because the entry node is an NN or
PBN rather than an EBN. The appnIsInRouteInfo object at NN/PBN
contains the same RSCV, as represented by (2).
3. NN or PBN connected to EBN
**subnet 1**|-----ISTG ------|**subnet 2**
NN/PBN EBN1
PLU SLU
---------------------------->|
(1) |---------->
(2)
The value of the appnIsInRouteInfo object at the NN/PBN is the
RSCV containing the route from the PLU to EBN1, represented by
(1). Note that the PLU must be in subnet 1, because the exit
node is an NN/PBN rather than an EBN. The appnIsInRouteInfo
object at EBN1 contains the same RSCV. The value of the
ebnIsRscvDestinationRoute object at EBN1 is the RSCV containing
the route from EBN1 to the SLU (or the next subnet's entry border
node), as represented by (2).
The following three cases illustrate the contents of
ebnIsRscvDestinationCos at Extended Border Nodes.
Clouston & Moore Standards Track [Page 6]
RFC 2457 Extended Border Node MIB November 1998
1. EBN connected to another EBN
**subnet 1**|-----ISTG ------|**subnet 2**
EBN1 EBN2
PLU SLU
COS A
---------------------------->|
COS B
|---------->
PLU = Primary Logical Unit (session initiator)
SLU = Secondary Logical Unit (session destination)
The value of ebnIsRscvDestinationCos object at EBN1 is COS A.
The value of ebnIsRscvDestinationCos object at EBN2 is COS B.
2. EBN connected to a NN or PBN
**subnet 1**|-----ISTG ------|**subnet 2**
EBN1 NN/PBN
PLU SLU
COS A
----------->|
COS B
|--------------------------->
The value of the ebvIsRscvDestinationCos object at EBN1 is COS B.
3. NN or PBN connected to EBN
**subnet 1**|-----ISTG ------|**subnet 2**
NN/PBN EBN1
PLU SLU
COS A
---------------------------->|
COS B
|---------->
The value of the ebnIsRscvDestinationCos object at the EBN2 is
COSB.
3.1.3 ebnDirConfig group
The ebnDirConfig group consists of simple objects that provide EBN-
specific information about directory caching and the local default
value for the maximum number of subnetworks a LOCATE search procedure
may traverse.
Clouston & Moore Standards Track [Page 7]
RFC 2457 Extended Border Node MIB November 1998
3.1.4 ebnCos group
The ebnCos group contains the ebnCosMapTable, which specifies how COS
values are mapped between the non-native subnetwork and the native
subnetwork.
3.1.5 ebnSubnetRoutingList group
The ebnSubnetRoutingList group contains information about the
customer-supplied EBN subnetwork routing list, which indicates to
which adjacent nodes an EBN will forward LOCATE search requests. It
consists of the following tables:
1. ebnSubnetSearchTable
This table has an entry for each LU name that has a defined
subnet routing list. The LU name may identify a single LU, or it
may contain a wildcard character that could identify a group of
LUs (partial wildcard) or all LUs (full wildcard). The objects
in the table indicate whether the EBN may add dynamic entries to
the subnet routing list, and whether the subnet routing list
entries may be reordered for better search performance.
2. ebnSearchTable
This table has an entry for each control point name which is
included in a multi-subnet search for a particular LU name. The
index to the table is the LU name to be searched for, and an
index which lists the order in which the CP names are to be
searched. Both the CP name and the LU name entries in the table
allow for partial and full wildcards. The CP name also allows
for special entries that indicate that the EBN will search
itself and its own native subnetwork at this point in the search,
or will search all native EBNs.
3.1.6 hbn group
The hbn group contains information about HBN (HPR EBN) intermediate
sessions. The hbnIsInTable is an extension to the appnIsInTable.
This table is present for intermediate sessions when there are back-
to-back RTP (Rapid Transport Protocol) connections in an HBN. It
provides the NCE ID (network connection endpoint identifier) and TCID
(transport connection identifier) for the second RTP connection.
Clouston & Moore Standards Track [Page 8]
RFC 2457 Extended Border Node MIB November 1998
4.0 Definitions
EBN-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Unsigned32
FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
DisplayString, TEXTUAL-CONVENTION
FROM SNMPv2-TC
SnaControlPointName
-- Because the characters allowed in an SNA control
-- point name come from a restricted character set,
-- these names are not subject to internationalization.
FROM APPN-MIB
snanauMIB
FROM SNA-NAU-MIB;
ebnMIB MODULE-IDENTITY
LAST-UPDATED "9804281800Z" -- April 28, 1998
ORGANIZATION "IETF SNA NAU MIB WG / AIW APPN MIBs SIG"
CONTACT-INFO
"
Bob Clouston
Cisco Systems
7025 Kit Creek Road
P.O. Box 14987
Research Triangle Park, NC 27709, USA
Tel: 1 919 472 2333
E-mail: clouston@cisco.com
Bob Moore
IBM Corporation
BRQA/501
P.O. Box 12195
Research Triangle Park, NC 27709, USA
Tel: 1 919 254 4436
E-mail: remoore@us.ibm.com
"
DESCRIPTION
" The MIB Module for Extended Border Node"
::= { snanauMIB 7 }
-- snanauMIB ::= { mib-2 34 }
Clouston & Moore Standards Track [Page 9]
RFC 2457 Extended Border Node MIB November 1998
-- ******************************************************************
-- Textual Conventions
-- ------------------------------------------------------------------
SnaNAUWildcardName ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Fully-qualified network NAU name. Entries take one of three
forms:
- Explicit entries do not contain the character '*'.
- Partial Wildcard entries have the form 'ccc*', where
'ccc' represents one to sixteen characters in a legal
SNA NAU Name.
- A full wildcard consists of a single character '*'.
Because the characters allowed in an SNA NAU name come from
a restricted character set, these names are not subject to
internationalization."
SYNTAX DisplayString(SIZE(1..17))
-- ******************************************************************
ebnObjects OBJECT IDENTIFIER ::= { ebnMIB 1 }
-- ******************************************************************
-- ******************************************************************
-- EBN Directory Group
-- The ebnDirTable is an extension to the appnDirTable. It specifies
-- the subnet affiliation for LUs in the EBN's directory.
-- ******************************************************************
ebnDir OBJECT IDENTIFIER ::= { ebnObjects 1 }
ebnDirTable OBJECT-TYPE
SYNTAX SEQUENCE OF EbnDirEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The EBN Directory Table. This table is an extension
to the APPN MIB's appnDirTable. Entries in this table
are in one-to-one correspondence with entries in the
appnDirTable, with corresponding entries having identical
values for their respective indexes."
::= { ebnDir 1 }
ebnDirEntry OBJECT-TYPE
SYNTAX EbnDirEntry
MAX-ACCESS not-accessible
Clouston & Moore Standards Track [Page 10]
RFC 2457 Extended Border Node MIB November 1998
STATUS current
DESCRIPTION
"Entry in the EBN Directory Table."
INDEX { ebnDirLuName }
::= { ebnDirTable 1 }
EbnDirEntry ::= SEQUENCE {
ebnDirLuName SnaNAUWildcardName,
ebnDirSubnetAffiliation INTEGER }
ebnDirLuName OBJECT-TYPE
SYNTAX SnaNAUWildcardName
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Fully qualified network LU name in the domain of a serving
network node. If this object has the same value as the
appnDirLuName object in the APPN MIB, then the two objects
are referring to the same LU."
::= { ebnDirEntry 1 }
ebnDirSubnetAffiliation OBJECT-TYPE
SYNTAX INTEGER { native (1),
nonNative (2),
subarea (3) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Specifies the subnetwork affiliation of the LU:
- native(1) : The LU is in the native APPN subnetwork.
- nonNative(2) : The LU is in a non-native APPN subnetwork.
- subarea(3) : The LU is in a subarea network."
::= { ebnDirEntry 2 }
-- ******************************************************************
-- EBN Intermediate Session RSCV Group
-- This table is a sparse extension to the appnIsInTable. For
-- sessions crossing ISTGs adjacent to the EBN, it contains the RSCV
-- and COS used in the direction of the BIND destination.
-- ******************************************************************
ebnIsRscv OBJECT IDENTIFIER ::= { ebnObjects 2 }
ebnIsRscvTable OBJECT-TYPE
Clouston & Moore Standards Track [Page 11]
RFC 2457 Extended Border Node MIB November 1998
SYNTAX SEQUENCE OF EbnIsRscvEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The EBN Intermediate Session RSCV table. This table is an
extension to the appnIsInTable. It contains the RSCV and COS
used in the direction of the BIND destination. There is an
entry in this table for each session that traverses an ISTG
when it enters or leaves this EBN, with corresponding entries
having identical values for their respective indexes."
::= { ebnIsRscv 1}
ebnIsRscvEntry OBJECT-TYPE
SYNTAX EbnIsRscvEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry in ebnIsRscvTable."
INDEX { ebnIsRscvCpName,
ebnIsRscvPcid }
::= { ebnIsRscvTable 1 }
EbnIsRscvEntry ::= SEQUENCE {
ebnIsRscvCpName SnaControlPointName,
ebnIsRscvPcid OCTET STRING,
ebnIsRscvDestinationRoute OCTET STRING,
ebnIsRscvDestinationCos DisplayString }
ebnIsRscvCpName OBJECT-TYPE
SYNTAX SnaControlPointName
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The network-qualified control point name of the node at
which the session and PCID originated. For APPN and LEN
nodes, this is either CP name of the APPN node at which
the origin LU is located or the CP name of the NN serving
the LEN node at which the origin LU is located. For DLUR
resources it is the name of the owning SSCP.
If this object has the same value as the appnIsInFqCpName
object in the APPN MIB, then the two objects are referring to
the same APPN control point."
::= { ebnIsRscvEntry 1 }
Clouston & Moore Standards Track [Page 12]
RFC 2457 Extended Border Node MIB November 1998
ebnIsRscvPcid OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (8))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The procedure correlation identifier (PCID) of a session.
It is an 8-octet value.
If this object has the same value as the appnIsInPcid object
in the APPN MIB, and if the corresponding ebnIsRscvCpName
object has the same value as the corresponding
appnIsInFqCpName object, then the entries indexed by these
objects are referring to the same session."
::= { ebnIsRscvEntry 2 }
ebnIsRscvDestinationRoute OBJECT-TYPE
SYNTAX OCTET STRING(SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The route selection control vector (RSCV x'2B') used in the
direction towards the SLU."
::= { ebnIsRscvEntry 3 }
ebnIsRscvDestinationCos OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..8))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Class of Service (COS) name used in the direction
towards the SLU.
Because the characters allowed in an SNA COS name come from
a restricted character set, these names are not subject to
internationalization."
::= { ebnIsRscvEntry 4 }
-- ******************************************************************
-- EBN Directory Config Group
-- The following simple objects provide information about EBN
-- directory.
-- ******************************************************************
ebnDirConfig OBJECT IDENTIFIER ::= { ebnObjects 3 }
Clouston & Moore Standards Track [Page 13]
RFC 2457 Extended Border Node MIB November 1998
ebnSearchCacheTime OBJECT-TYPE
SYNTAX Unsigned32
UNITS "minutes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The amount of time in minutes an extended border node will
retain information about a multi-subnetwork search, once
that that search terminates. A value 0 indicates that the
EBN has no defined limit, and the number of entries is
bounded only by memory."
::= { ebnDirConfig 1 }
ebnMaxSearchCache OBJECT-TYPE
SYNTAX Unsigned32
UNITS "entries"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum number of multi-subnet entries to be cached.
The value 0 indicates that the local node has no defined
limit, and the number of entries is bounded only by
memory."
::= { ebnDirConfig 2 }
ebnDefaultSubnetVisitCount OBJECT-TYPE
SYNTAX Unsigned32
UNITS "topology subnetworks"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The default maximum number of subnetworks a LOCATE search
procedure may traverse."
::= { ebnDirConfig 3 }
-- ******************************************************************
-- EBN COS Mapping Group
-- The ebnCosMap Table specifies how non-native COS values are mapped
-- to COS values defined in the native subnetwork. The COS mappings
-- that an EBN performs are determined by multiple factors, one of
-- which is a set of user-defined mappings. This table returns the
-- COS mappings that the EBN is actually performing, rather than
-- the user-defined mappings.
-- ******************************************************************
Clouston & Moore Standards Track [Page 14]
RFC 2457 Extended Border Node MIB November 1998
ebnCOS OBJECT IDENTIFIER ::= { ebnObjects 4 }
ebnCosMapTable OBJECT-TYPE
SYNTAX SEQUENCE OF EbnCosMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The EBN COS Mapping Table. This table specifies how non-
native COS values are mapped to COS values defined in the
native subnetwork.
Note: The COS mappings that an EBN performs are determined
by multiple factors, one of which is a set of user-defined
initial mappings. This table returns the COS mappings that
the EBN is actually performing at the time it is queried,
rather than the user-defined initial ones."
::= { ebnCOS 1 }
ebnCosMapEntry OBJECT-TYPE
SYNTAX EbnCosMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the EBN COS Mapping table."
INDEX { ebnCosMapCpName,
ebnCosMapNonNativeCos }
::= { ebnCosMapTable 1 }
EbnCosMapEntry ::= SEQUENCE {
ebnCosMapCpName SnaNAUWildcardName,
ebnCosMapNonNativeCos DisplayString,
ebnCosMapNativeCos DisplayString }
ebnCosMapCpName OBJECT-TYPE
SYNTAX SnaNAUWildcardName
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Fully qualified network CP name for which the COS mapping
applies."
::= { ebnCosMapEntry 1 }
ebnCosMapNonNativeCos OBJECT-TYPE
SYNTAX DisplayString (SIZE(1..8))
Clouston & Moore Standards Track [Page 15]
RFC 2457 Extended Border Node MIB November 1998
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object contains one of the following values:
- An 8-character COS name used in a non-native subnetwork.
- The single character '*', identifying the entry with the
default native COS for a non-native CP name. This entry
is used when there is no entry in the table for a
non-native CP name / non-native COS pair.
Because the characters allowed in an SNA COS name come from
a restricted character set, these names are not subject to
internationalization."
::= { ebnCosMapEntry 2 }
ebnCosMapNativeCos OBJECT-TYPE
SYNTAX DisplayString (SIZE(1..8))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An 8-byte name for the class-of-service, as known in the
native subnetwork.
Because the characters allowed in an SNA COS name come from
a restricted character set, these names are not subject to
internationalization."
::= { ebnCosMapEntry 3 }
-- ******************************************************************
-- EBN Subnet Routing List Group
-- The EBN Subnet Routing List indicates to which nodes an EBN
-- forwards search request. This group contains information
-- pertaining to the CONFIGURED Subnet Routing List at an EBN. How a
-- particular search request is routed is determined by a transient
-- list that the EBN creates based on the configured list and other
-- factors.
-- *******************************************************************
ebnSubnetRoutingList OBJECT IDENTIFIER ::= { ebnObjects 5 }
ebnSubnetSearchTable OBJECT-TYPE
SYNTAX SEQUENCE OF EbnSubnetSearchEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
Clouston & Moore Standards Track [Page 16]
RFC 2457 Extended Border Node MIB November 1998
"This table contains one entry for each fully qualified LU
name for which an associated subnet routing list has been
defined. An entry in this table contains general
characteristics of the subnet search routing list for an
LU name. The routing list itself is represented by a set
of contiguous entries in the ebnSearchTable."
::= { ebnSubnetRoutingList 1 }
ebnSubnetSearchEntry OBJECT-TYPE
SYNTAX EbnSubnetSearchEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry for the ebnSubnetSearchTable. The entry
represents the configured parameters the EBN uses when it
is determining how to search for the LU identified by the
ebnSubnetSearchLuName object."
INDEX { ebnSubnetSearchLuName }
::= { ebnSubnetSearchTable 1 }
EbnSubnetSearchEntry ::= SEQUENCE {
ebnSubnetSearchLuName SnaNAUWildcardName,
ebnSubnetSearchDynamics INTEGER,
ebnSubnetSearchOrdering INTEGER }
ebnSubnetSearchLuName OBJECT-TYPE
SYNTAX SnaNAUWildcardName
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Fully qualified network LU name."
::= { ebnSubnetSearchEntry 1 }
ebnSubnetSearchDynamics OBJECT-TYPE
SYNTAX INTEGER { none(1),
limited (2),
full (3) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates whether an EBN may add dynamic entries to a
subnetwork routing list. none(1) means no entries may be
added to the subnetwork routing list. limited(2) means
only likely entries may be added to the subnetwork routing
Clouston & Moore Standards Track [Page 17]
RFC 2457 Extended Border Node MIB November 1998
list. full(3) means all native extended border nodes and
adjacent, non-native EBNs and NNs will be added to the
subnetwork routing list."
::= { ebnSubnetSearchEntry 2 }
ebnSubnetSearchOrdering OBJECT-TYPE
SYNTAX INTEGER{ priority(1),
defined(2) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates whether an EBN may reorder a subnetwork routing
list so that entries which are more likely to be successful
move to the top of the subnetwork routing list and entries
which are more likely to be unsuccessful move to the bottom
of the list.
The following values are defined:
- priority(1): Entries may be reordered.
- defined(2): Entries must not be reordered."
::= { ebnSubnetSearchEntry 3 }
-- Border node search table
ebnSearchTable OBJECT-TYPE
SYNTAX SEQUENCE OF EbnSearchEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table indicates the CONFIGURED list of control points
to which the EBN sends Locate searches for a given fully
qualified LU name. Each entry in the table indicates one
control point that should be included in a multi-subnet
search for a particular LU name."
::= { ebnSubnetRoutingList 2 }
ebnSearchEntry OBJECT-TYPE
SYNTAX EbnSearchEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the ebnSearchTable. An entry can exist in
this table only if an entry exists in the
ebnSubnetSearchTable with an ebnSubnetSearchLuName value
matching this entry's ebnSearchLuName.
Clouston & Moore Standards Track [Page 18]
RFC 2457 Extended Border Node MIB November 1998
For a given ebnSearchLuName value, the ordering of entries
provides by the ebnSearchIndex values corresponds to the
order in which the control points to be searched appear in
the CONFIGURED search list for the ebnSearchLuName."
INDEX { ebnSearchLuName,
ebnSearchIndex }
::= { ebnSearchTable 1 }
EbnSearchEntry ::= SEQUENCE {
ebnSearchLuName SnaNAUWildcardName,
ebnSearchIndex Unsigned32,
ebnSearchCpName DisplayString,
ebnSearchSNVC Unsigned32 }
ebnSearchLuName OBJECT-TYPE
SYNTAX SnaNAUWildcardName
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Fully qualified network LU name. If this object has the
same value as the ebnSubnetSearchLuName object, then the
two objects are referring to the same LU."
::= { ebnSearchEntry 1 }
ebnSearchIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Secondary index enumerating the CONFIGURED order in which
a search is forwarded to CPs for a particular LU name. The
order for an actual search is determined dynamically by the
EBN, based on this configured information and on other
factors, including whether search dynamics and search
ordering are enabled. Information on these last two settings
is available in, respectively, the ebnSubnetSearchDynamics
and ebnSubnetSearch ordering objects."
::= { ebnSearchEntry 2 }
ebnSearchCpName OBJECT-TYPE
SYNTAX DisplayString(SIZE(1..17))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Clouston & Moore Standards Track [Page 19]
RFC 2457 Extended Border Node MIB November 1998
"This object specifies the CP(s) to which a search should be
forwarded. It either follows the SnaNAUWildcardName textual
convention or takes one of the following special formats:
'*' indicates that all native EBNs and all adjacent non-
native EBNs and NNs may be added to the routing list
dynamically,
'*SELF' indicates that the EBN should search itself and
its native subnetwork at this time during the
cross-subnet search,
'*EBNS' indicates all native EBNs.
Because the characters allowed in a CP name come from a
restricted character set, and because the three formats
listed here use no special characters, this object is not
subject to internationalization."
::= { ebnSearchEntry 3 }
ebnSearchSNVC OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum number of subnets a Locate search procedure may
traverse. "
::= { ebnSearchEntry 4 }
-- *******************************************************************
-- HPR Extended Border Node Intermediate Session Group
-- The hbnIsInTable is a sparse extension to the appnIsInTable.
-- For sessions that use back-to-back RTP connections in an HBN,
-- this table provides the network connection endpoint identifier
-- (NceId) and the transport connection identifier (Tcid) for the
-- second RTP connection.
-- *******************************************************************
hbn OBJECT IDENTIFIER ::= { ebnObjects 6 }
hbnIsInTable OBJECT-TYPE
SYNTAX SEQUENCE OF HbnIsInEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The HBN Intermediate Session table."
Clouston & Moore Standards Track [Page 20]
RFC 2457 Extended Border Node MIB November 1998
::= { hbn 1}
hbnIsInEntry OBJECT-TYPE
SYNTAX HbnIsInEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entry of the HBN Intermediate Session Table. An entry
exists in this table for every intermediate session being
routed between back-to-back RTP connections in the HBN.
When an entry for a session exists in this table, the
NceIds and Tcids for the back-to-back RTP connections are
made available in the following four objects:
RTP connection in the direction of the PLU:
- NceId: appnIsInRtpNceId (in the APPN MIB)
- Tcid: appnIsinRtpTcid (in the APPN MIB).
RTP connection in the direction of the SLU:
- NceId: hbnIsInRtpNceId (in this table)
- Tcid: hbnIsInRtpTcid (in this table)."
INDEX { hbnIsInFqCpName,
hbnIsInPcid }
::= { hbnIsInTable 1 }
HbnIsInEntry ::= SEQUENCE {
hbnIsInFqCpName SnaControlPointName,
hbnIsInPcid OCTET STRING,
hbnIsInRtpNceId OCTET STRING,
hbnIsInRtpTcid OCTET STRING }
hbnIsInFqCpName OBJECT-TYPE
SYNTAX SnaControlPointName
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The network-qualified control point name of the node at
which the session and PCID originated. For APPN and LEN
nodes, this is either the CP name of the APPN node at
which the origin LU is located or the CP name of the NN
serving the LEN node at which the origin LU is located.
If this object has the same value as the appnIsInFqCpName
object in the APPN MIB, then the two objects are referring
to the same APPN control point."
Clouston & Moore Standards Track [Page 21]
RFC 2457 Extended Border Node MIB November 1998
::= { hbnIsInEntry 1 }
hbnIsInPcid OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(8))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The procedure correlation identifier (PCID) of a session.
It is an 8-octet value.
If this object has the same value as the appnIsInPcid object
in the APPN MIB, and if the corresponding hbnIsInFqCpName
object has the same value as the corresponding
appnIsInFqCpName object, then the entries indexed by these
objects are referring to the same session."
::= { hbnIsInEntry 2 }
hbnIsInRtpNceId OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1..8))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The HPR local Network Connection Endpoint of the session in
the direction of the SLU."
::= { hbnIsInEntry 3 }
hbnIsInRtpTcid OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(8))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The RTP connection local TCID of the session in the direction
of the SLU."
::= { hbnIsInEntry 4 }
-- *******************************************************************
-- Conformance Statement
-- *******************************************************************
ebnConformance OBJECT IDENTIFIER ::= { ebnMIB 2 }
ebnCompliances OBJECT IDENTIFIER ::= { ebnConformance 1 }
ebnGroups OBJECT IDENTIFIER ::= { ebnConformance 2 }
-- Compliance statements
ebnCompliance MODULE-COMPLIANCE
Clouston & Moore Standards Track [Page 22]
RFC 2457 Extended Border Node MIB November 1998
STATUS current
DESCRIPTION
"The compliance statement for the SNMPv2 entities which
implement the ebnMIB."
MODULE -- this module
-- Unconditionally mandatory groups
MANDATORY-GROUPS {
ebnDirectoryGroup,
ebnIsRscvGroup,
ebnDirectoryConfigGroup,
ebnCosMappingGroup,
ebnSubnetRoutingListGroup }
-- Conditionally mandatory groups
GROUP hbnIsInGroup
DESCRIPTION
"The hbnIsInGroup is mandatory only for HPR extended border
nodes."
::= {ebnCompliances 1 }
-- Group definitions
ebnDirectoryGroup OBJECT-GROUP
OBJECTS { ebnDirSubnetAffiliation }
STATUS current
DESCRIPTION
"The EBN-related directory objects."
::= { ebnGroups 1 }
ebnIsRscvGroup OBJECT-GROUP
OBJECTS { ebnIsRscvDestinationRoute,
ebnIsRscvDestinationCos }
STATUS current
DESCRIPTION
"Two objects representing RSCV and class of service
information saved by an EBN."
::= { ebnGroups 2 }
ebnDirectoryConfigGroup OBJECT-GROUP
OBJECTS { ebnSearchCacheTime,
ebnMaxSearchCache,
ebnDefaultSubnetVisitCount }
STATUS current
Clouston & Moore Standards Track [Page 23]
RFC 2457 Extended Border Node MIB November 1998
DESCRIPTION
"The EBN Directory Configuration Group."
::= { ebnGroups 3 }
ebnCosMappingGroup OBJECT-GROUP
OBJECTS { ebnCosMapNativeCos }
STATUS current
DESCRIPTION
"The EBN COS Mapping Group."
::= { ebnGroups 4 }
ebnSubnetRoutingListGroup OBJECT-GROUP
OBJECTS { ebnSubnetSearchDynamics,
ebnSubnetSearchOrdering,
ebnSearchCpName,
ebnSearchSNVC }
STATUS current
DESCRIPTION
"The Subnet Routing List Group."
::= { ebnGroups 5 }
hbnIsInGroup OBJECT-GROUP
OBJECTS { hbnIsInRtpNceId, hbnIsInRtpTcid }
STATUS current
DESCRIPTION
"The HBN-related Intermediate Session Objects."
::= { ebnGroups 6 }
END
5.0 Security Considerations
Certain management information defined in this MIB may be considered
sensitive in some network environments. Therefore, authentication of
received SNMP requests and controlled access to management
information SHOULD be employed in such environments. An
authentication protocol is defined in [10]. A protocol for access
control is defined in [11].
None of the read-only objects in the EBN MIB reports a password, user
data, or anything else that is particularly sensitive. Some
enterprises view their network configuration itself, as well as
information about network usage and performance, as corporate assets;
Clouston & Moore Standards Track [Page 24]
RFC 2457 Extended Border Node MIB November 1998
such enterprises may wish to restrict SNMP access to most of the
objects in the MIB.
There are no read-write objects in the EBN MIB.
6.0 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 implementers 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.
7.0 Acknowledgments
This MIB module is the product of the IETF SNA NAU MIB WG and the AIW
APPN/HPR MIBs SIG. Thanks to Dave Billing, Cisco Systems; Katie Lee,
IBM Corporation; and Marcia Peters, IBM Corporation, for their
contributions and review.
8.0 References
[1] Case, J., Fedor, M. Schoffstall, M. and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.
[2] McCloghrie, K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets: MIB-II", STD 17,
RFC 1213, March 1991.
[3] Case, J., McCloghrie, K., Rose, M., and Waldbusser S.,
"Structure of Management Information for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1902, January 1996.
Clouston & Moore Standards Track [Page 25]
RFC 2457 Extended Border Node MIB November 1998
[4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Textual
Conventions for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1903, January 1996.
[5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Conformance Statements for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1904, January 1996.
[6] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1905, January 1996.
[7] Harrington D., Presuhn, R. and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2271, January 1998.
[8] Harrington D., Presuhn, R. and B. Wijnen, "Message Processing
and Dispatching for the Simple Network Management Protocol
(SNMP)", RFC 2272, January 1998.
[9] Levi D., Meyer P. and B. Stewart, "SNMPv3 Applications", RFC
2273, January 1998.
[10] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol
(SNMPv3)", RFC 2274, January 1998.
[11] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2275, January 1998.
[12] Hovey, R. and S. Bradner, "The Organizations Involved in the
IETF Standards Process", BCP 11, RFC 2028, October 1996.
[13] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[14] Clouston, B. and B. Moore, "Definition of Managed Objects for
APPN", RFC 2455, November 1998.
[15] IBM, APPN Extended Border Node Architecture Reference Version
1.0, available only via anonymous FTP at
networking.raleigh.ibm.com, as
/pub/standards/aiw/appn/bordernode/ebn4.psbin.
[16] IBM, SNA/MS Formats, GC31-8302-01
Clouston & Moore Standards Track [Page 26]
RFC 2457 Extended Border Node MIB November 1998
9.0 Authors' Addresses
Bob Clouston
Cisco Systems
7025 Kit Creek Road
P.O. Box 14987
Research Triangle Park, NC 27709, USA
Phone: +1-919-472-2333
EMail: clouston@cisco.com
Robert Moore
Dept. BRQA/Bldg. 501/G114
IBM Corporation
P.O.Box 12195
3039 Cornwallis
Research Triangle Park, NC 27709, USA
Phone: +1-919-254-4436
EMail: remoore@us.ibm.com
Clouston & Moore Standards Track [Page 27]
RFC 2457 Extended Border Node MIB November 1998
10.0 Full Copyright Statement
Copyright (C) The Internet Society (1998). 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.
Clouston & Moore Standards Track [Page 28]