📄 rfc2457.txt
字号:
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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -