tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3371

Proposed STD
Pages: 70
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: L2TPEXT

Layer Two Tunneling Protocol "L2TP" Management Information Base

Part 1 of 3, p. 1 to 11
None       Next RFC Part

 


Top       ToC       Page 1 
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).

Top       Page 2 
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].

Top      ToC       Page 3 
   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.

Top      ToC       Page 4 
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.

Top      ToC       Page 5 
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.

Top      ToC       Page 6 
   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

Top      ToC       Page 7 
   The corresponding ifStack table entries would then be:

           ifStackTable Entries

           HigherLayer  LowerLayer
           0            5
           0            6
           0            7
           1            0
           2            1
           3            2
           4            2
           5            2
           6            2
           7            3
           7            4

   L2TP Access Concentrator (LAC) tunnel interfaces on the other hand
   appear at the top of the interface layering stack.  In this case the
   layering model is as described in [RFC2667].

   However in order to support the tunneling of packets received from
   interfaces carrying framed PPP packets on the LAC to the LNS (and the
   propagation of decapsulated PPP packets to that interface) additional
   configuration is required.  This is further described in section 3.4.

3.1.2  Interface MIB Objects

   Except where noted in the tables below, all objects MUST be supported
   from the ifGeneralInformationGroup and one of the following three
   groups:

      o ifPacketGroup OR
      o ifHCPacketGroup OR
      o ifVHCPacketGroup

   depending on the particular implementation.

   The following tables describe how objects from the
   ifGeneralInformationGroup and ifPacketGroup (similar support should
   be provided for the high and very high capacity packet groups) are to
   be interpreted and supported for L2TP tunnel interfaces.

3.1.2.1  L2TP Tunnel Interfaces

   All Interface MIB objects not listed in the above groups for L2TP
   tunnel interfaces MUST be supported as described in [RFC2863].

Top      ToC       Page 8 
      Interface MIB Object    Support Description
      ====================    ========================================
      ifTable.ifDescr         Refer to the Interface MIB.

      ifTable.ifType          tunnel(131).

      ifTable.ifMtu           Dependent on the tunnel transport layer.
                              For UDP/IP transports the MTU should
                              be 65467 (65535-60(IP)-8(UDP)).

      ifTable.ifSpeed         Return zero.

      ifTable.ifPhyAddress    The assigned tunnel identifier.

      ifTable.ifAdminStatus   Setting ifAdminStatus to 'up' injects a
                              'Local Open' request into the tunnel FSM.
                              Setting ifAdminStatus to 'down' injects
                              a 'Tunnel Close' event into the tunnel
                              FSM.  Setting ifAdminStatus to 'testing'
                              is not currently defined but could be
                              used to test tunnel connectivity.

      ifTable.ifOperStatus    ifOperStatus values are to be interpreted
                              as follows:
                              'up'             - tunnel is established.
                              'down'           - administratively down
                                                 or peer unreachable.
                              'testing'        - in some test mode.
                              'unknown'        - status cannot be
                                                 determined for some
                                                 reason.
                              'dormant'        - operational but
                                                 waiting for local or
                                                 remote trigger to bring
                                                 up the tunnel.
                              'notPresent'     - configuration missing.
                              'lowerLayerDown' - down due to state of
                                                 lower-layer
                                                 interface(s).

      ifTable.ifInOctets      The total number of octets received on the
                              tunnel including control and payload
                              octets.

      ifTable.ifInUcastPkts   The total number of packets received on
                              the tunnel including control and payload
                              packets.

Top      ToC       Page 9 
      ifTable.ifInDiscards    The total number of received packets that
                              were discarded on both control and payload
                              channels.

      ifTable.ifInErrors      The total number of packets received in
                              error including control and payload
                              packets.

      ifTable.ifInUnknownProtos
                              Return zero.

      ifTable.ifOutOctets     The total number of octets transmitted
                              from the tunnel including control and
                              payload octets.

      ifTable.ifOutUcastPkts  The total number of packets transmitted
                              from the tunnel including control and
                              payload packets.

      ifTable.ifOutDiscards   The total number of discarded packets that
                              were requested to be transmitted including
                              control and payload packets.

      ifTable.ifOutErrors     The total number of packets that were
                              requested to be transmitted that were in
                              error including control and payload
                              packets.

      ifXTable.ifName         Refer to the Interface MIB.

      ifXTable.ifInMulticastPkts
                              Return zero.

      ifXTable.ifInBroadcastPkts
                              Return zero.

      ifXTable.ifOutMulticastPkts
                              Return zero.

      ifXTable.ifOutBroadcastPkts
                              Return zero.

      ifXTable.ifOutBroadcastPkts
                              Return zero.

      ifXTable.ifLinkUpDownTrapEnable
                              Default set to enabled(1).

Top      ToC       Page 10 
      ifXTable.ifHighSpeed    Return zero.

      ifXTable.ifPromiscuousMode
                              Set to false(2).

      ifXTable.ifConnectorPresent
                              Set to false(2).

3.2  Relationship to other MIBs

3.2.1  Relationship to the IP Tunnel MIB

   The IP Tunnel MIB [RFC2667] describes tunnel interfaces that have an
   ifType of tunnel(131).  The IP Tunnel MIB is considered to contain a
   collection of objects common to all IP tunneling protocols, including
   L2TP.  In addition to the IP Tunnel MIB, tunnel encapsulation
   specific MIBs (like this MIB) extend the IP Tunnel MIB to further
   describe encapsulation specific information.  Implementation of the
   IP Tunnel MIB is required for L2TP tunnels over IP.

3.3  L2TP Tunnel Creation

   Tunnel creation is detailed for tunnels over IP in the IP Tunnel MIB.
   The creation of a tunnelIfEntry in [RFC2667] when the encapsulation
   method is "l2tp" will have the side effect of creating entries in the
   l2tpTunnelConfigTable, l2tpTunnelStatsTable and the
   l2tpUdpStatsTable's.

   The creation of L2TP tunnel interfaces over transports other than IP
   is expected to be defined in the MIB definition for that specific
   L2TP tunnel transport.

3.4  L2TP Session Mapping

   The l2tpSessionMapTable table allows management applications to
   determine which session within a tunnel a particular interface
   (either a PPP or DS0 interface) is mapped to.  On the LAC it also
   provides a management application the ability to map a particular
   physical or virtual interface terminating a PPP link to a particular
   L2TP tunnel.  This is required since the interface stacking as
   performed (and instrumented by the ifStackTable) on the LNS cannot be
   applied at the LAC.

Top      ToC       Page 11 
   The following diagram illustrates the conceptual binding that occurs.

             +---------------------------------------+
             |       L2TP Session Map Database       |
             +----------+-----------------+----------+
                        |                 |
                    +---+---+       +-----+------+
                    |  ds0  |       | Tunnel I/F |
                    +---+---+       +-----+------+
                        |                 |
                    +---+---+       +-----+------+
                    |  ds1  |       |  Ethernet  |
                    +-------+       +------------+

   The stacking of the individual interface stacks would be described by
   the ifStackTable.



(page 11 continued on part 2)

Next RFC Part