This MIB Module models status, performance and failures
        of a protocol with the generic characteristics of signalling 
        protocols used with IPsec and FC-SP protocols. Examples
        of such protocols include IKE, KINK, etc. This MIB views the
        common attributes of such protocols. Signaling protocols are
        also referred in this document as 'Control Protocols', since 
        they perform session control.
        
        This MIB is an attempt to capture the generic aspects 
        of the signaling activity. The protocol-specific aspects
        of a signaling protocol still need to be captured 
        in a protocol-specific MIB (e.g., CISCO-IKE-FLOW-MIB, etc.).
        
        Acronyms
        The following acronyms are used in this document:
        
           IPsec:      Secure IP Protocol
        
           VPN:        Virtual Private Network
        
           ISAKMP:     Internet Security Association and Key Exchange
      Protocol
        
           IKE:        Internet Key Exchange Protocol
        
           SA:         Security Association 
  (ref: rfc2408).
        
           Phase 1 Tunnel:
      An ISAKMP SA can be regarded as representing
      a flow of ISAKMP/IKE traffic. Hence an ISAKMP
      is referred to as a 'Phase 1 Tunnel' in this
      document. 
        
           Control Tunnel:
      Another term for a Phase 1 Tunnel.
        
           Phase 2 Tunnel:
      An instance of a non-ISAKMP SA  bundle in which all
      the SA share the same proxy identifiers (IDii,IDir)
      protect the same stream of application traffic.
      Such an SA bundle is termed a 'Phase 2 Tunnel'.
      Note that a Phase 2 tunnel may comprise different
      SA bundles and different number of SA bundles at
      different times (due to key refresh).
        
        
        History of the MIB
         A precursor to this MIB was the IPsec Flow Monitor MIB, which
         combined the objects pertaining to IKE and IPsec (Phase-2)
         into a single MIB module. Furthermore, the MIB supported only
         one signaling protocol, IKEv1, in addition to manual keying.
        
         The MIB was written by Tivoli and implemented in IBM Nways 
         routers in 1999. During late 1999, Cisco adopted the MIB and 
         together with Tivoli publised the IPsec Flow Monitor MIB in 
         IETF IPsec WG in draft-ietf-ipsec-flow-monitoring-mib-00.txt. 
         In 2000, the MIB was Cisco-ized and implemented as
         CISCO-IPSEC-FLOW-MONITOR-MIB in IOS and VPN3000 platforms.
        
         With the evolution of IKEv2, the MIB was modified and 
         presented to the IPsec WG again in May 2003 in
         draft-ietf-ipsec-flow-monitoring-mib-02.txt.
        
         With the emergence to multiple signaling protocols, it has
         further evolved to define separate set of MIB modules to 
         instrument IPsec signaling alone. Thus, this MIB module
         is now the generic IPsec signaling MIB.
          
        Overview of MIB
         The MIB contains major groups of objects which are
         used to manage the generic aspects of IPsec signaling. 
         These groups include a global statistics, control tunnel table,
         Peer association group, control tunnel history group,
         signaling failure group and notification group.
        
         The global statistics, tunnel table and peer association
         groups aid in the real-time monitoring of IPsec signaling
         activity.
        
         The History group is to aid applications that do
         trending analysis.
        
         The Failure group is to enable an operator to
         do troubleshooting and debugging.
         Further, counters are supported to aid detection
         of potential security violations.
        
         The notifications are modeled as generic IPsec control 
         notifications and are parameterized by the identity of the
         specific signaling protocol which caused the notification
         to be issued.