rfc2457.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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.