Subject: [ipfix-protocol] PROTO-25, PROTO-31, PROTO-32, PROTO-33: SCTP/Sequence ID + Template

From: Benoit Claise <[email-masked]>
Date: Fri, 22 Oct 2004 17:27:57 +0200

Dear all,

The issues PROTO-25, PROTO-31, PROTO-32, PROTO-33 (look at the end of 
the email for a description) are linked to each others; they relate to 
the SCTP streams, the sequence ID, and the way the templates are sent.
Stewart and I are closed to propose a solution for all those 4 issues 
combined. However, we wanted to double check a couple of things before, 
and post some new text on the mailing list for discussion ... instead 
of  updating directly the IPFIX protocol draft just before the deadline!
So we commit to propose a solution on the mailing before the next IETF 
meeting.

Regards, Stewart and Benoit.

----------------------------------------

    PROTO-25: The section "Template Management" and "The Collecting
   Process's Side" will have to updated according to the transport
   protocol.
       - For example, the point 2 of the section "Template Management".
         Remark: the template management will vary with TCP, SCTP,  
         etc...
         Must have both sections updated: transport updated and 
         template management sections (BTW, this is the same for the 
         failover section).
       - From Deri's draft: On the other hand as a probe can send flows
       to several collectors (e.g. in round-robin or as a reflector) it
       must keep track of per-collector templates transmission. This
       means that if collector X reconnects, the probe must send the
       template only to this collector and not to all collectors.
       
     PROPOSAL, after IETF60: treat UDP as the exception, in the template
     subsection of the UDP transport protocol.
   
   PROTO-31 The "Sequence Number" and "Source ID" treatment in case of
   multiple streams in SCTP is not well described. For example, in case
   the Templates are sent to one stream and the flow records to another
   one, what should the "Sequence Number"? What should the collector
   do? See David Moore's post  

   PROTO-32 Correct this issue below

     The Collecting Process SHOULD verify that the received IPFIX
     Messages inside one stream do not have differing Source ID values
     and silently discard any data that does NOT match the initial
     value. 

     The Exporting Process SHOULD NOT transmit messages inside one
     stream with multiple Source ID values. The correlated Flow Records
     are then treated like a normal export Flow.

   PROTO-33: correct the next paragraphs: silently? reset the
   connection? log an error? should the exporting process be allowed to
   sent multiple Source ID per stream.

        The Collecting Process SHOULD verify that the received IPFIX
        Messages inside one stream do not have differing Source ID
        values and silently discard any data that does NOT match the
        initial value. 

        The Exporting Process SHOULD NOT transmit messages inside one
        stream with multiple Source ID values. The correlated Flow
        Records are then treated like a normal export Flow.

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/