Subject: RE: [ipfix] Some ideas on IPFIX-architecture

From: "Gopal Ram (NRC/Boston)" <[email-masked]>
Date: Wed, 12 Dec 2001 09:00:45 -0500

Sorry earlier emails slipped out my hands.
 
Hello all,

(1) Archicture should identify key elements which are going to
participate in the IPFIX protocol.
(2) We should keep in mind that IPFIX is not going existing on its own
its has relations with Diameter,
Intrusion Detection subsystem 
(3) Should describe ( not define ) these external dependency and
internal interfaces between 
different sub systems.
(4) Any precondition and out of scope should be state here as well as in
the requirements.
(5) Should come up with sample scenarios or explaining with a 
reference model.

In principle "Architecture" should not cover (impose )any solution - it
should describe the entities involved in 
IPFIX protocol.
Regards
Ramg

>>-----Original Message-----
>>From: ext Kevin Zhang [mailto:[email-masked]]
>>Sent: Tuesday, December 11, 2001 12:18 AM
>>To: [email-masked]
>>Subject: [ipfix] Some ideas on IPFIX-architecture
>>
>>
>>Hi All,
>>
>>As we are getting started to work on the IPFIX architecture, I 
>>would like to offer few ideas to assist the discussion.  
>>Hopefully, we can touch on these issues at our Wed. session.
>>
>>1.  General Scope of IPFIX architecture.
>>
>>The IPFIX architecture should describe the major functions 
>>performed by a IPFIX system.  We need to answer the following 
>>questions -
>>1.1  What is the IPFIX system and what are the key functions 
>>performed by such a system? 
>>1.2  What are the major functional elements (e.g. data 
>>exporter, data collector, etc.) within the IPFIX system? 
>>1.3  How to assign key IPFIX functions to various IPFIX 
>>elements? What are the interfaces and supported protocols? 
>>Reference models should be specified.
>>
>>2. IPFIX Scenarios
>>
>>2.1 The exporter and the collector are connected over LAN or 
>>dedicated links. This scenario maybe suitable for handling 
>>high volume data export and may use unreliable transport protocol.
>>2.2 The exporter and the collector are connected over WAN. 
>>This scenario may require higher level of processing at the 
>>exporter (such as aggregation), and should use a reliable 
>>transport protocol with congestion control and avoidance capability. 
>>2.3 Highly reliable IPFIX configuration.  This scenario should 
>>describe how to support reliability of data export as well as 
>>redundant configurations.
>>
>>3. Data transport Semantics
>>
>>We need to specify the required control information exchange 
>>between the layers and between the end points.  This would set 
>>up the correct context for export IP flow information to meet 
>>various application (billing, traffic profiling, etc.) requirement. 
>>
>>
>>éi(tm)¨¥¶?sZSÝ¢j'z×hSÜ"±Ç¹©Ý±¬¡zZbzg¬±¨n?rR{.nÇ+?·¦j)m¢f£¢·hs?Þ
>>µÚ"·¬qçnjwlk+§²æìr¸>z*_<§(tm)ë,j>¡ÜEURÈb½èm¶YÿS-âÅÚ"·¬qçnýªÜ?+Þ
>>
>

--
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/