Subject: [MIB-DOCTORS] IPFIX MIB: ipfixTransportSessionIndex and sctpAssocId

From: Benoit Claise <[email-masked]>
Date: Thu, 25 Jan 2007 11:50:26 +0100

Dear all,

One more design question regarding the IPFIX-MIB.

   ipfixTransportSessionTable  OBJECT-TYPE
       SYNTAX      SEQUENCE OF IpfixTransportSessionEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "This table lists the currently established transport
           sessions between an exporting process and a collecting
           process."
       ::= { ipfixObjects 2 }
 
   ipfixTransportSessionEntry OBJECT-TYPE
       SYNTAX      IpfixTransportSessionEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the ipfixTransportSessionTable"
       INDEX       { ipfixTransportSessionIndex }           <------------
       ::= { ipfixTransportSessionTable 1 }
 
   IpfixTransportSessionEntry ::=
       SEQUENCE {
          ipfixTransportSessionIndex                  Integer32,
          ipfixTransportSessionProtocol               Integer32,
          ipfixTransportSessionAddressType            InetAddressType,
          ipfixTransportSessionSourceAddress          InetAddress,
          ipfixTransportSessionDestinationAddress     InetAddress,
          ipfixTransportSessionSourcePort             Integer32,
          ipfixTransportSessionDestinationPort        Integer32,
          ipfixTransportSessionSctpAssocId            Unsigned32,        
<------------
          ipfixTransportSessionTemplateRefreshTimeout Unsigned32,
          ipfixTransportSessionOptionTemplateRefreshTimeout Unsigned32,
          ipfixTransportSessionGroupId                Unsigned32,
          ipfixTransportSessionGroupMemberType        INTEGER,
          ipfixTransportSessionStatus                 INTEGER
       }
   ipfixTransportSessionSctpAssocId OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The association id used for the SCTP session between the
           exporter and the collector of the IPFIX transport session.
           It equals to the sctpAssocId
entry in the sctpAssocTable defined in the
           SCTP MIB. This object is only valid if
           ipfixTransportSessionProtocol has the value 132 (SCTP)."
       ::= { ipfixTransportSessionEntry 8 }

   ipfixTransportSessionIndex OBJECT-TYPE
       SYNTAX      Integer32 (0..2147483647)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Locally arbitrary, but unique identifier of an entry in
           the ipfixTransportSessionTable. The value is expected to
           remain constant from a re-initialization of the entity's
           network management system to the next re-initialization.
 
           The special value of zero (0) is reserved for use within
           the ipfixObservationDomainTable."

I've been trying to see if we could reuse sctpAssocId (RFC 3873) instead 
of the ipfixTransportSessionIndex
 
   sctpAssocId OBJECT-TYPE
     SYNTAX         Unsigned32 (1..4294967295)
     MAX-ACCESS     not-accessible
     STATUS         current
     DESCRIPTION
          "Association Identification. Value identifying the
          association. "
 
     ::= { sctpAssocEntry 1 }
 
I see the advantages:
- we don't need the ipfixTransportSessionSctpAssocId in the table
- the management is easier: from the IPFIX MIB, we can directly poll the 
information in the SCTP MIB
 
However, the drawbacks are that:
- there is a dependency on the SCTP MIB
- this would not work for UDP and TCP transport protocol

Here is a proposal.
Since sctpAssocId is Unsigned32, why not use ipfixTransportSessionIndex 
as Unsigned64 with the following assignment
bit 0 to 31: reserved for UDP or TCP
bit 32 to 62: contain the sctpAssocId. The value is 0 if UDP or TCP is used.

The advantage is that, in case of SCTP, the values of 
ipfixTransportSessionIndex and sctpAssocId are identical. The only 
difference is that ipfixTransportSessionIndex is 64 bits, while 
sctpAssocId is 32 bits. The disadvantage: we increase the bandwidth 
requirement as the table index is longer.
 
We would like to request your feedback:
    Do we make this unnecessary complicated?
    Is it worth the pain to save one MIB variable?

Regards, Benoit.
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors