Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

PROPOSED STANDARD
Network Working Group                                        B. CloustonRequest for Comments: 2457                                 Cisco SystemsCategory: Standards Track                                       B. Moore                                                         IBM Corporation                                                           November 1998Definitions of Managed Objectsfor Extended Border NodeStatus 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 Contents1.0  Introduction  . . . . . . . . . . . . . . . . . . . . . . .22.0  The SNMP Network Management Framework   . . . . . . . . . .23.0  Overview  . . . . . . . . . . . . . . . . . . . . . . . . .33.1  EBN MIB Structure   . . . . . . . . . . . . . . . . . . . .43.1.1  enbDir group  . . . . . . . . . . . . . . . . . . . . .53.1.2  ebnIsRscv group   . . . . . . . . . . . . . . . . . . .53.1.3  ebnDirConfig group  . . . . . . . . . . . . . . . . . .73.1.4  ebnCos group  . . . . . . . . . . . . . . . . . . . . .83.1.5  ebnSubnetRoutingList group  . . . . . . . . . . . . . .83.1.6  hbn group   . . . . . . . . . . . . . . . . . . . . . .84.0  Definitions   . . . . . . . . . . . . . . . . . . . . . . .95.0  Security Considerations   . . . . . . . . . . . . . . . . .246.0  Intellectual Property   . . . . . . . . . . . . . . . . . .257.0  Acknowledgments   . . . . . . . . . . . . . . . . . . . . .258.0  References  . . . . . . . . . . . . . . . . . . . . . . . .25Clouston & Moore            Standards Track                     [Page 1]

RFC 2457                Extended Border Node MIB           November 19989.0  Authors' Addresses  . . . . . . . . . . . . . . . . . . . .2710.0  Full Copyright Statement   . . . . . . . . . . . . . . . .281.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 inRFC 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 inRFC 2271 [7].   o   the SMI, described inRFC 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/orRFC 1905 [6] and/orRFC2272 [8] -- the protocol for accessing managed information.   o   the user-based security model defined inRFC 2274 [10].   o   the view-based access control model defined inRFC 2275 [11].   Textual conventions are defined inRFC 1903 [4], and conformance   statements are defined inRFC 1904 [5].  Common applications are   defined inRFC 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 19983.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.  TheClouston & 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 19983.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 19984.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-accessibleClouston & 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-TYPEClouston & 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        DESCRIPTIONClouston & 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 routingClouston & 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        DESCRIPTIONClouston & 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-COMPLIANCEClouston & 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 currentClouston & 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 }  END5.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 inBCP-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",RFC2273, 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-01Clouston & Moore            Standards Track                    [Page 26]

RFC 2457                Extended Border Node MIB           November 19989.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.comClouston & Moore            Standards Track                    [Page 27]

RFC 2457                Extended Border Node MIB           November 199810.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]

[8]ページ先頭

©2009-2025 Movatter.jp