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

---

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:
>
>       INDEX       { ipfixTransportSessionSctpAssocId,
>                     ipfixTransportSessionNonSCTPIndex }
>           ipfixTransportSessionNonSCTPIndex           Integer32,
>        SYNTAX      Unsigned32  (0..4294967295)
>            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
>            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.
>
>        ::= { 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:
>
>> Dear all,
>>
>> 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 
>> the information in the SCTP MIB
>>
>> Since sctpAssocId is Unsigned32, why not use 
>> ipfixTransportSessionIndex as Unsigned64 with the following assignment

---

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:

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: Benoit Claise <[email-masked]>
Date: Thu, 25 Jan 2007 15:30:35 +0100

Chris,
Oops. I forgot that!

Regards, Benoit.

---

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

Benoit,

Chris.

On Thu, 25 Jan 2007, Benoit Claise wrote:

>         ipfixTransportSessionSourcePort             IntegeFrom [email-masked] Thu Jan 25 12:24:34 2007
Date: Thu, 25 Jan 2007 11:50:26 +0100
From: Benoit Claise <[email-masked]>
To: [email-masked], [email-masked]
Cc: 
Subject: [MIB-DOCTORS] IPFIX MIB: ipfixTransportSessionIndex and sctpAssocId 

This is a multi-part message in MIME format.
--===============1656010460==
Content-Type: multipart/alternative;
	boundary="------------030903040303010903070308"

This is a multi-part message in MIME format.
--------------030903040303010903070308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

 

 

   sctpAssocId OBJECT-TYPE
 
     ::= { sctpAssocEntry 1 }
 
I see the advantages:

Here is a proposal.

Regards, Benoit.

--------------030903040303010903070308
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<span style="">Dear all,<br>
<br>
One more design question regarding the IPFIX-MIB.<br>
<br>
&nbsp;&nbsp;
</span>ipfixTransportSessionTable<span style="">&nbsp; </span>OBJECT-TYPE<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>SYNTAX<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>SEQUENCE
OF IpfixTransportSessionEntry<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>MAX-ACCESS<span style="">&nbsp; </span>not-accessible<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>STATUS<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>current<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>DESCRIPTION<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>"This table lists the currently established transport<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>sessions
between an exporting process and a collecting<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>process."<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>::= {
ipfixObjects 2 }<o:p></o:p>
<br>
<o:p>&nbsp;</o:p>
<br>
<span r32,

style="">&nbsp;&nbsp;
</span>ipfixTransportSessionEntry OBJECT-TYPE<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>SYNTAX<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>IpfixTransportSessionEntry<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>MAX-ACCESS<span style="">&nbsp; </span>not-accessible<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>STATUS<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>current<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>DESCRIPTION<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>"Defines an entry in the ipfixTransportSessionTable"<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>INDEX<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>{
ipfixTransportSessionIndex }<o:p></o:p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;------------<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>::= {
ipfixTransportSessionTable 1 }<o:p></o:p>
<o:p></o:p><br>
<span style="" lang="SV"><o:p>&nbsp;</o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp; </span>IpfixTransportSessionEntry
::=<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>SEQUENCE {<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>ipfixTransportSessionIndex<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Integer32,<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>ipfixTransportSessionProtocol<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Integer32,<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>ipfixTransportSessionAddressType<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>InetAddressType,<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>ipfixTransportSessionSourceAddress<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>InetAddress,<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>ipfixTransportSessionDestinationAddress<span style="">&nbsp;&nbsp;&nbsp;&nbsp; </span>InetAddress,<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>ipfixTransportSessionSourcePort<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Integer32,<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>ipfixTransportSessionDestinationPort<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Integer32,<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>ipfixTransportSessionSctpAssocId<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Unsigned32,<o:p></o:p></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;------------<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>ipfixTransportSessionTemplateRefreshTimeout Unsigned32,<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>ipfixTransportSessionOptionTemplateRefreshTimeout Unsigned32,<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="">&nbsp;&nbsp;</span>ipfixTransportSessionGroupId<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Unsigned32,<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>ipfixTransportSessionGroupMemberType<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>INTEGER,<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>ipfixTransportSessionStatus<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>INTEGER<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>}<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp; </span>ipfixTransportSessionSctpAssocId
OBJECT-TYPE<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>SYNTAX<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Unsigned32<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>MAX-ACCESS<span
 style="">&nbsp; </span>read-only<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span>STATUS<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>current<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>DESCRIPTION<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>"The association id used for the SCTP session between the<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>exporter
and the collector of the IPFIX transport session.<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>It equals to the sctpAssocId <o:p></o:p>
<br>
entry in the sctpAssocTable defined in the<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>SCTP
MIB. This object is only valid if<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>ipfixTransportSessionProtocol has the value 132 (SCTP)."<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>::= {
ipfixTransportSessionEntry 8 }<br>
<br>
<br>
<span style="">&nbsp;&nbsp; </span>ipfixTransportSessionIndex
OBJECT-TYPE<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="" lang="SV">SYNTAX<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>Integer32 (0..2147483647)<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>MAX-ACCESS<span
 style="">&nbsp; </span>not-accessible<o:p></o:p></span>
<br>
<span style="" lang="SV"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span>STATUS<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>current<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>DESCRIPTION<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>"Locally arbitrary, but unique identifier of an entry in<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="">&nbsp;</span>the
ipfixTransportSessionTable. The value is
expected to<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>remain
constant from a re-initialization of the entity's<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>network
management system to the next re-initialization.<o:p></o:p>
<br>
<o:p>&nbsp;</o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>The
special value of zero (0) is reserved for use within<o:p></o:p>
<br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>the
ipfixObservationDomainTable."<o:p></o:p><br>
<br>
I&#8217;ve been trying to see if we could reuse sctpAssocId (RFC 3873)
instead of the <span style=""></span>ipfixTransportSessionIndex
<o:p></o:p><br>
<o:p>&nbsp;</o:p><br>
<span style="">&nbsp;&nbsp; </span>sctpAssocId OBJECT-TYPE<o:p></o:p><br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp; </span>SYNTAX<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Unsigned32
(1..4294967295)<o:p></o:p><br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp; </span>MAX-ACCESS<span style="">&nbsp;&nbsp;&nbsp;&nbsp; </span>not-accessible<o:p></o:p><br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="" lang="FR">STATUS<span
 style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>current<o:p></o:p></span><br>
<span style="" lang="FR"><span style="">&nbsp;&nbsp;&nbsp;&nbsp; </span>DESCRIPTION<o:p></o:p></span><br>
<span style="" lang="FR"><span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>"Association
Identification. </span>Value identifying the<o:p></o:p><br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>association. "<o:p></o:p><br>
<o:p>&nbsp;</o:p><br>
<span style="">&nbsp;&nbsp;&nbsp;&nbsp; </span>::= { sctpAssocEntry 1 }<o:p></o:p>
<br>
<o:p>&nbsp;</o:p>
<br>
I see the advantages:<o:p></o:p>
<br>
- we don't need the ipfixTransportSessionSctpAssocId in the table<br>
- the management is easier<o:p></o:p>: from the IPFIX MIB, we can
directly poll the information in the SCTP MIB<br>
<o:p>&nbsp;</o:p>
<br>
However, the drawbacks are that:<br>
- there is a dependency on the SCTP MIB<br>
- this would not work for UDP and TCP transport protocol<br>
<br>
<!--[if !supportLists]--><o:p>Here is a proposal.<br>
Since </o:p><span style=""></span>sctpAssocId is <span style=""></span>Unsigned32,
why not use <span style=""></span>ipfixTransportSessionIndex
as <span style=""></span>Unsigned64 with the following assignment<br>
bit 0 to 31: reserved for UDP or TCP<br>
bit 32 to 62: contain the <span style=""></span>sctpAssocId. The value
is 0 if UDP or TCP is used.<br>
<br>
The advantage is that, in case of SCTP, the values of <span style=""></span>ipfixTransportSessionIndex
and <span style=""></span>sctpAssocId are identical. The only
difference is that <span style=""></span>ipfixTransportSessionIndex
is 64 bits, while <span style=""></span>sctpAssocId is 32 bits. The
disadvantage: we increase the bandwidth requirement as the table index
is longer.<br>
<o:p>&nbsp;</o:p>
<br>
We would like to request your feedback:<br>
&nbsp;&nbsp;&nbsp; Do we make this unnecessary complicated?<br>
&nbsp;&nbsp;&nbsp; Is it worth the pain to save one MIB variable?<br>
<br>
Regards, Benoit. <o:p></o:p><br>
<o:p></o:p>
</body>
</html>

--------------030903040303010903070308--

--===============1656010460==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============1656010460==--

---

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

Chris,
Oops. I forgot that!

Regards, Benoit.

---

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

Benoit,

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.

On Fri, 26 Jan 2007, kobayashi atsushi wrote:

> 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.
>
>       INDEX       { ipfixTransportSessionProtocol,
>                     ipfixTransportSessionIndex }
>           ipfixTransportSessionIndex                  Unsigned32,
>           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
> Benoit Claise <[email-masked]> wrote:
>
>> Chris,
>>> Benoit,
>>>
>> IPFIX mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ipfix
>
> ---
> 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: 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: "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.
> > >>>>