rfc3371.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,749 行 · 第 1/5 页

Network Working Group                                           E. Caves
Request for Comments: 3371                                Occam Networks
Category: Standards Track                                     P. Calhoun
                                                    Black Storm Networks
                                                              R. Wheeler
                                                     DoubleWide Software
                                                             August 2002


                  Layer Two Tunneling Protocol "L2TP"
                      Management Information Base


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 (2002).  All Rights Reserved.

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in TCP/IP-based internets.
   In particular, it defines objects for managing networks using Layer 2
   Tunneling Protocol (L2TP).




















Caves, et. al.              Standards Track                     [Page 1]

RFC 3371            L2TP Management Information Base         August 2002


Table of Contents

   1.0      Introduction   ..........................................  2
   2.0      The SNMP Management Framework ...........................  2
   3.0      Overview ................................................  4
   3.1      Relationship to the Interface MIB........................  5
   3.1.1    Layering Model ..........................................  5
   3.1.2    Interface MIB Object.....................................  7
   3.1.2.1  L2TP Tunnel Interfaces ..................................  7
   3.2      Relationship to other MIBs .............................. 10
   3.2.1    Relationship to the IP Tunnel MIB ....................... 10
   3.3      L2TP Tunnel Creation .................................... 10
   3.4      L2TP Session Mapping .................................... 10
   4.0      L2TP Object Definitions ................................. 11
   5.0      Security Considerations ................................. 66
   6.0      Acknowledgements ........................................ 67
   7.0      References .............................................. 67
   8.0      Authors' Addresses ...................................... 69
   9.0      Full Copyright Statement ................................ 70

1.0 Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet Community.
   In particular, it describes managed objects used for managing L2TP
   devices.

   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 [RFC2119].

2.0 The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

   o An overall architecture, described in RFC 2571 [RFC2571].

   o Mechanisms for describing and naming objects and events for the
     purpose of management.  The first version of this Structure of
     Management Information (SMI) is called SMIv1 and described in STD
     16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215
     [RFC1215].  The second version, called SMIv2, is described in STD
     58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC
     2580 [RFC2580].






Caves, et. al.              Standards Track                     [Page 2]

RFC 3371            L2TP Management Information Base         August 2002


   o Message protocols for transferring management information.  The
     first version of the SNMP message protocol is called SNMPv1 and
     described in STD 15, RFC 1157 [RFC1157].  A second version of the
     SNMP message protocol, which is not an Internet standards track
     protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and
     RFC 1906 [RFC1906].  The third version of the message protocol is
     called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572
     [RFC2572] and RFC 2574 [RFC2574].

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

   o A set of fundamental applications described in RFC 2573 [RFC2573]
     and the view-based access control mechanism described in RFC 2575
     [RFC2575].

   A more detailed introduction to the current SNMP Management Framework
   can be found in RFC 2570 [RFC2570].

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

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
















Caves, et. al.              Standards Track                     [Page 3]

RFC 3371            L2TP Management Information Base         August 2002


3.0 Overview

   The objects defined in this MIB are to be used when describing Layer
   Two Tunneling Protocol (L2TP) tunnels.  The L2TP protocol is defined
   in [RFC2661].  This MIB consists of seven groups briefly described
   below:

   l2tpConfigGroup
   l2tpStatsGroup
      These two groups of objects provide information on the
      configuration, state and statistics of the L2TP protocol, its
      tunnels and sessions.  These groups are mandatory for implementors
      of this MIB.

   l2tpDomainGroup
      This optional group of objects provides configuration, state and
      statistical information for L2TP tunnel endpoint domains.  A L2TP
      tunnel endpoint domain is considered to be a collection of L2TP
      devices typically belonging to a common administrative domain or
      geographic location.

   l2tpMappingGroup
      This optional group contains mapping tables to assist management
      applications to map between protocol identifiers and table
      indices.

   l2tpIpUdpGroup
      This group provides the state and statistics information for L2TP
      tunnels which are being transported by UDP/IP.  This group is
      mandatory for L2TP implementations that support L2TP over UDP/IP.

   l2tpSecurityGroup
      This group is optional for SNMP agents which support both
      authentication and privacy of SNMP messages for the management of
      L2TP keys.

   l2tpTrapGroup
      This group contains the notifications that could be generated by a
      L2TP implementation.

   l2tpHCPacketGroup
         This group is optional for L2TP implementations that could
         potentially overflow the L2TP Domain tables 32-bit statistics
         counters in less than an hour.







Caves, et. al.              Standards Track                     [Page 4]

RFC 3371            L2TP Management Information Base         August 2002


3.1 Relationship to the Interface MIB

   This section clarifies the relationship of this MIB to the Interfaces
   MIB [RFC2863].  Several areas of correlation are addressed in the
   following subsections.  The implementor is referred to the Interfaces
   MIB document in order to understand the general intent of these
   areas.

3.1.1  Layering Model

   This MIB contains several tables which are extensions to the IP
   Tunnel MIB described in [RFC2667] which itself defines extensions to
   the Interface MIB [RFC2863].  An L2TP tunnel is represented as a
   separate identifiable logical interface sub-layer.  The tunnel stack
   layering model is described in [RFC2667].

   In addition to that described in [RFC2667] an L2TP tunnel will not be
   at the top of the ifStack on a L2TP device that is acting as a L2TP
   Network Server (LNS).  In this case PPP interfaces will be layered on
   top of the tunnel interface.































Caves, et. al.              Standards Track                     [Page 5]

RFC 3371            L2TP Management Information Base         August 2002


   In the example diagram below, the interface layering is shown as it
   might appear at the LNS.

       +--------------------------------------------+
       |           Network Layer Protocol           |
       +-+-----------+-------------+--------+-------+
         |           |             |        |
         |         +-+--+          |        |
         |         |MPPP|          |        |    <=== PPP Multilink I/F
         |         ++--++          |        |
         |          |  |           |        |
         |       +--+  +--+        |        |
         |       |        |        |        |
         |     +-+-+    +-+-+    +-+-+    +-+-+
         |     |PPP|    |PPP|    |PPP|    |PPP|  <=== PPP I/F
         |     +-+-+    +-+-+    +-+-+    +-+-+
         |       |        |        |        |
         |  +----+--------+--------+--------+----+
         |  |           L2TP Tunnel I/F          |
         |  +------------------+-----------------+
         |                     |
       +-+---------------------+------+
       |            Ethernet          |
       +------------------------------+

   The ifStackTable is used to describe the layering of the interface
   sub-layers.  For the example given above the ifTable and ifStackTable
   may appear as follows:

   ifIndex ifType        Tunnel MIB tables       Description

      1    ethernetCsmacd(6)                     Ethernet interface
      2    tunnel(131)   tunnelIfTable           Tunnel interface
                         l2tpTunnelConfigTable
                         l2tpTunnelStatsTable
      3    ppp(23)                               PPP interface #1
      4    ppp(23)                               PPP interface #2
      5    ppp(23)                               PPP interface #3
      6    ppp(23)                               PPP interface #4
      7    mlppp(108)                            MLPPP interface











Caves, et. al.              Standards Track                     [Page 6]

RFC 3371            L2TP Management Information Base         August 2002


   The corresponding ifStack table entries would then be:

           ifStackTable Entries

           HigherLayer  LowerLayer
           0            5
           0            6
           0            7