Subject: [IPFIX] 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.
_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 25 Jan 2007 13:03:14 +0100

Benoit,

I'm not a MIB expert but I have never seen an index variable being
crafted "bit by bit" like this. At the end, you have an artificial value
without implicit meaning.

I assume the common way would be to have ipTransportSessionIndex
separated from ipfixTransportSessionAssocId. Since
ipfixTransportSessionAssocId=sctpAssocId, you can then directly look up
more information in the SCTP-MIB.

Regards,
Gerhard

Benoit Claise wrote:
> I’ve been trying to see if we could reuse sctpAssocId (RFC 3873) instead
> - the management is easier : from the IPFIX MIB, we can directly poll
> the information in the SCTP MIB
>  
> ------------------------------------------------------------------------
> 

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Sand 13 (Room B309), D-72076 Tuebingen, Germany
Phone:  +49 7071 29-70534       Fax: +49 7071 29-5220
E-mail: [email-masked]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 25 Jan 2007 13:03:14 +0100

Benoit,

Regards,
Gerhard

---

From: Chris Elliott <[email-masked]>
Date: Thu, 25 Jan 2007 08:38:29 -0500 (EST)

Benoit,

SNMP doesn't define Unsigned64. Just Counter64. And using Counter64 would 
be a hack. Further, it would exclude the use of SNMPv1 to poll this table.

I'd rather doubly-index the table and redefine ipfixTransportSessionIndex 
to be used just for non-SCTP transports. Here's a MIB fragment:

   ipfixTransportSessionEntry OBJECT-TYPE
       SYNTAX      IpfixTransportSessionEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the ipfixTransportSessionTable"
       INDEX       { ipfixTransportSessionSctpAssocId,
                     ipfixTransportSessionNonSCTPIndex }
       ::= { ipfixTransportSessionTable 1 }

           ipfixTransportSessionNonSCTPIndex           Integer32,

    ipfixTransportSessionSctpAssocId OBJECT-TYPE
        SYNTAX      Unsigned32  (0..4294967295)
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
            "The association id used for the SCTP session between the
            exporter and the collector of the IPFIX transport session.
            It equals the sctpAssocId in the sctpAssocTable
            defined in the SCTP MIB. If ipfixTransportSessionProtocol
            does not have the value 132 (SCTP) then the value of this
            object shall be zero (0)."
        ::= { ipfixTransportSessionEntry 1 }

    ipfixTransportSessionNonSCTPIndex OBJECT-TYPE
        SYNTAX      Integer32 (0..2147483647)
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
            "Locally arbitrary, but unique identifier of an entry in
            the ipfixTransportSessionTable if
            ipfixTransportSessionProtocol does not have the value 132
            (SCTP). The value of one (1) shall be used if
            ipfixTransportSessionProtocol does have the value 132 (SCTP).

            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."
        ::= { ipfixTransportSessionEntry 2 }

This way, a row in this table can be accessed, for SCTP sessions by 
specifying the instance ".<sctpAssocId>.1".

While the use of zero is discouraged as an index value, placing 
ipfixTransportSessionSctpAssocId first, thus ensuring that the aggregate 
index will not end in zero, should meet the spirit of this rule.

Of course, all objects following these two in this table will have to be 
renumbered due to this reordering.

Chris.

On Thu, 25 Jan 2007, Benoit Claise wrote:

> I've been trying to see if we could reuse sctpAssocId (RFC 3873) instead of 
> the ipfixTransportSessionIndex
>
>  sctpAssocId OBJECT-TYPE
> Since sctpAssocId is Unsigned32, why not use ipfixTransportSessionIndex as 
> Unsigned64 with the following assignment
> 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.
>

-- 
Chris Elliott  CCIE# 2013       |         |
Customer Diagnostic Engineer   |||       |||
RTP, NC, USA                  |||||     |||||
919-392-2146              .:|||||||||:|||||||||:.
[email-masked]        c i s c o S y s t e m s

---

From: Chris Elliott <[email-masked]>
Date: Thu, 25 Jan 2007 08:38:29 -0500 (EST)

Benoit,

Chris.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 25 Jan 2007 15:30:35 +0100

Chris,
> Benoit,
>
> SNMP doesn't define Unsigned64. Just Counter64. 
Oops. I forgot that!
This alone kills the proposal :)

Thanks for the nice proposal below.

Regards, Benoit.
> And using Counter64 would be a hack. Further, it would exclude the use 
> of SNMPv1 to poll this table.
>
> I'd rather doubly-index the table and redefine 
> ipfixTransportSessionIndex to be used just for non-SCTP transports. 
> Here's a MIB fragment:
>
> ipfixTransportSessionSctpAssocId first, thus ensuring that the 
> aggregate index will not end in zero, should meet the spirit of this 
> rule.
>
> Of course, all objects following these two in this table will have to 
> be renumbered due to this reordering.
>
> Chris.
>
>> I've been trying to see if we could reuse sctpAssocId (RFC 3873) 
>> instead of the ipfixTransportSessionIndex
>>
>>  sctpAssocId OBJECT-TYPE
>> - the management is easier: from the IPFIX MIB, we can directly poll 
>> Since sctpAssocId is Unsigned32, why not use 
>> ipfixTransportSessionIndex as Unsigned64 with the following assignment

---

From: Benoit Claise <[email-masked]>
Date: Thu, 25 Jan 2007 15:30:35 +0100

Chris,
Oops. I forgot that!

Regards, Benoit.

---

From: kobayashi atsushi <[email-masked]>
Date: Fri, 26 Jan 2007 10:58:12 +0900

Benoit and Chris,

I see the double indexes.

If ipfixTransportSessionProtocol and ipfixTransportSessionIndex become
the indexes as following table, ipfixTransportSessionIndex can refer
sctpAssocId directly. How about this?

 ipfixTransportSessionTable
 * ipfixTransportSessionProtocol
 * ipfixTransportSessionIndex --> if sctp, sctpAssocId is used.
   ipfixTransportAddressType
   ipfixTransportSessionSourceAddress
   ipfixTransportSessionDestinationAddress
   ipfixTransportSessionSourcePort
   ipfixTransportSessionDestinationPort
   ipfixTransportSessionSctpAssocId --> remove

If the name of sctpAssocId is used directly, there is a dependency on
the SCTP MIB. I think it's better that object name is not referred
directly.

   ipfixTransportSessionEntry OBJECT-TYPE
       SYNTAX      IpfixTransportSessionEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Defines an entry in the ipfixTransportSessionTable"
       INDEX       { ipfixTransportSessionProtocol,
                     ipfixTransportSessionIndex }
       ::= { ipfixTransportSessionTable 1 }

           ipfixTransportSessionIndex                  Unsigned32,

           The special value of zero (0) is reserved for use within
           the ipfixObservationDomainTable.

           if ipfixTransportSessionProtocol have the value 132(SCTP), 
           the value is able to equal the sctpAssocId in the
           sctpAssocTable defined in the SCTP MIB."

On Thu, 25 Jan 2007 15:30:35 +0100

> >>         ipfixTransportSessionSctpAssocId            Unsigned32, 

--- 
Atsushi KOBAYASHI  <[email-masked]>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637

---

From: kobayashi atsushi <[email-masked]>
Date: Fri, 26 Jan 2007 10:58:12 +0900

Benoit and Chris,

 

---

---

From: Chris Elliott <[email-masked]>
Date: Fri, 26 Jan 2007 04:11:10 -0500 (EST)

Atsushi KOBAYASHI,

I think the concern is that there could be overlap in the values used for 
sctpAssocId and those used for non-SCTP sessions. This MIB module cannot 
guarantee there will not be a collision of values because it does not 
control the values selected for sctpAssocId. No matter what value is 
picked for the index for a non-SCTP session it's possible that a new SCTP 
session would use the same index.

Chris.

---

From: Chris Elliott <[email-masked]>
Date: Fri, 26 Jan 2007 04:11:10 -0500 (EST)

Atsushi KOBAYASHI,

Chris.

---

From: kobayashi atsushi <[email-masked]>
Date: Mon, 29 Jan 2007 21:52:49 +0900

Chris,

I understand your proposal.

Even if ipfixTransportSessionIndex overlaps between SCTP and non-SCTP,
the index pair of ipfixTransportSessionProtocol and
ipfixTransportSessionIndex can be avoided overlapping as indexes.
By indexes of ipfixTransportSessionProtocol and ipfixTransportSessionIndex,
the value of ipfixTransportSessionIndex can be allocated within each
protocol and can share sctpAssocId.

On the point of view about dependency on SCTP, I think that it is better.

Best Regards,
Atsushi KOBAYASHI

On Fri, 26 Jan 2007 04:11:10 -0500 (EST)

---

---

From: kobayashi atsushi <[email-masked]>
Date: Mon, 29 Jan 2007 21:52:49 +0900

Chris,

Best Regards,
Atsushi KOBAYASHI

---

---

From: "David Harrington" <[email-masked]>
Date: Tue, 30 Jan 2007 15:38:42 -0500

Hi,

I agree that using {protocol, sessionIndex} to create a discriminated
union avoids the problem of overlapping sessionIndex values, and would
allow the sessionIndex to be the value of the corresponding
sctpAssocId. 

David Harrington
[email-masked] 
[email-masked]
[email-masked]
IETF MIB Doctor

> -----Original Message-----
> From: kobayashi atsushi [mailto:[email-masked]] 
> Sent: Monday, January 29, 2007 7:53 AM
> To: Chris Elliott
> Cc: [email-masked]; [email-masked]
> Subject: Re: [IPFIX] IPFIX MIB: ipfixTransportSessionIndex 
> and sctpAssocId
> 
> 
> Chris,
> 
InetAddress,
> > >           ipfixTransportSessionDestinationAddress
InetAddress,
> InetAddress,
> InetAddress,
Integer32,
> > >>>           ipfixTransportSessionDestinationPort
Integer32,
> InetAddress,
> InetAddress,
Integer32,
> > >>>>         ipfixTransportSessionDestinationPort
Integer32,
> > >>>> bit 32 to 62: contain the sctpAssocId. The value is 0 
> if UDP or TCP
> > >>>> is used.
> > >>>>

---

From: "David Harrington" <[email-masked]>
Date: Tue, 30 Jan 2007 15:38:42 -0500

Hi,

David Harrington
[email-masked] 
[email-masked]
[email-masked]
IETF MIB Doctor

InetAddress,
InetAddress,
Integer32,
Integer32,
Integer32,
Integer32,