From majordomo@mil.doit.wisc.edu Mon Apr 1 14:05:04 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10959 for ; Mon, 1 Apr 2002 14:05:03 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16s6fw-0001vt-00 for ipfix-list@mil.doit.wisc.edu; Mon, 01 Apr 2002 12:37:04 -0600 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16s6ft-0001ug-00 for ipfix-arch@net.doit.wisc.edu; Mon, 01 Apr 2002 12:37:01 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g31IaPK15235; Mon, 1 Apr 2002 10:36:25 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-17.cisco.com [171.71.137.17]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABS95873; Mon, 1 Apr 2002 10:36:33 -0800 (PST) Message-ID: <3CA8A88F.A6D27750@cisco.com> Date: Mon, 01 Apr 2002 10:35:59 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: <12205450.1017371280@[192.168.102.31]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Jurgene, Tanja, Juergen Quittek wrote: > Hi KC, > > Here is a revised version of the terminology for the > architecture document (as promised in Minneapolis). > Most of the changes result from discussions with Tanja. > > The definitions of IPFIX device, template, control > stream and data stream are unchanged, although I am > not yet completely satisfied with them. > Further discussion on all terms seems to be ahead. > > Cheers, > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > Terminology > > * IP Traffic Flows > A flow is defined as a set of packets passing an observation > domain in the network during a certain time interval. All packets > belonging to a particular flow have a set of common properties. > Each property is defined as the result of applying a function to > the values of: > > 1. one or more of packet header fields (eg. destination IP > address) > 2. one or more properties of the packet itself (eg. packet length) > 3. one or more of fields derived from packet treatment (eg. AS > number) > > A packet is defined to belong to a flow if it completely > satisfies all the defined properties of the flow. The sentence "Each of the fields from 1., 2. and 3. are referred to as keys. " (from the arch spec) seems to be omitted here. This is required for introducing the definition of flow type. What I feel is appropriate is to pick up the entire defintion including examples from the data model doc and stick it here also. > > > This definition covers the range from a flow containing all > packets observed at a network interface to a flow consisting of > just a single packet between two applications with a specific > sequence number. The range could be broader. A flow could contain all packets observed at one or more network interfaces. > Please note that the flow definition does not > match a general application-level end-to-end stream. I am not sure I understand this? A flow "could" match a general application-level end-to-end stream. But it is not restricted to this only. Is there a need to mention these lines or do you think the flow defintion is not clear enough? > However, > an application may derive properties of application-level > streams by processing measured flow data. > > * Observation Point > The observation point is a location in the network where IP > packets can be observed. Examples are a line to which a probe > is attached, a shared medium, such as an Ethernet-based LAN, > a single port of a router, or the routing engine of a router. Why is "a set of interfaces (physical or logical) of a router" from the arch. spec omitted? Aggregation of ports (like fast ether channels in Cisco routers) is used very much in deployments. > > > * Observation Domain > A single IP traffic flow may contain packets observed at several > different observation points, for example at several ports of a > line card or at different probes. The observation domain of a > flow is the set of observation points at which the packets of > this flow have been or might have been observed. The minimal > observation domain contains just a single observation point. From the definition above , it would mean if R1 and R2 collect {Src AS, dst AS} on their respective n/w interfaces I1 and I2, then {I1, I2} would make up an observation domain!! Let me try to explain what I had in mind on this defintion: The flows collected from various observation points could be subjected to a series of sampling and classification operation in some sequence. This result could be combining flows collected at different observation points. An example for this is: The raw flow (5-tuple) collected at 2 observation points O1 and O2, when a furthur classification is done to choose all the packets that match a certain destination address would result in aggregation within the node (by node I mean a router or a linecard which can be clearly identified as a network entity and capable of doing such aggregation). Observation domain consists of the set of observation points, the metering processes, the part of maintenance of flow records (which includes functions like aggregation) and choosing a criteria for export. > > > * Metering Process > The metering process generates flow records. Input to the > process are IP packets observed in an observation domain. The > metering process consists of a set of functions that includes > packet header capturing, timestamping, sampling, classifying, > and maintaining flow records. > > Sampling and classifying may be performed repeatedly (with > different parameters). The sampling function selects a subset > of the received set of items (packet headers with timestamps or > flow records) to be passed further to the classifying function. > The sampling function may be trivial by passing all items, > which is equivalent to applying no sampling at all. The > classifying function maps its input to flows. There are two > extreme classifying functions: one mapping each packet to > different flows and one mapping all packets to the same flow. > > Maintenance of flow records may include creating new records, > updating existing ones, computing flow statistics, deriving further > flow properties, detecting flow expiration, passing flows record to > the exporting process, and deleting flow records. Maintenance of flow record can be thought of as a function of observation domain . One more functionality which is outside the metering process is a selection criteria for export. > > > The figure below shows the sequence in which the functions are applied. > > packet header capturing > | > timestamping > | > v > +----->+ > | | > | sampling > | | > | classifying > | | > +------+ > | > maintaining flow records > | > v > > Figure 1: Functions of the metering process > > * Flow Record > A flow record contains information about a specific flow that was > metered in an observation domain. A flow record contains measured > properties of the flow (e.g. the total number of bytes of all packets > of the flow) and usually characteristic properties of the flow (e.g. > source IP address). > > * Exporting Process > The exporting process sends flow records to one or more collectors. > The flow records are generated by one or more metering processes. There could be an option export criteria at the observation domain which chooses which records to export. Ganesh > > > * Collecting Process > The collecting process receives flow records from one or more exporting > processes. The collecting process might store received flow record > or further process them, but these actions are out of the scope of > this document. > > * IPFIX Device: > A device hosting at least an observation point, a metering > process and a flow information export process. Typically, > corresponding observation point(s), metering process(es), and > exporter process(es) are co-located at this device, for example, > at a router. > > * Template: > Templates is a set of {type, length} ordered pairs, used to > completely identify the structure and semantics of a particular > information that needs to be communicated from the IPFIX Device > to the collector. Each template is uniquely identified by a > Template ID. > > * Control Stream, Data Stream: > The information that needs to be exported from the IPFIX device > can be classified into the following categories: > > - Control Information : > This includes the flow type definition, selection criteria > for packets within the flow. This is also called as Control > Stream. > - Flow record : > This includes data records corresponding to the various > observed flows at each of the observation point. This is also > called as Data Stream. > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Apr 1 16:55:41 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16479 for ; Mon, 1 Apr 2002 16:55:40 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16s9VJ-0005gj-00 for ipfix-list@mil.doit.wisc.edu; Mon, 01 Apr 2002 15:38:17 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16s9VG-0005gR-00 for ipfix-arch@net.doit.wisc.edu; Mon, 01 Apr 2002 15:38:15 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g31LbiQ89849; Mon, 1 Apr 2002 23:37:44 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.32] ([192.168.102.32]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA03291; Mon, 1 Apr 2002 23:37:33 +0200 Date: Mon, 01 Apr 2002 23:40:35 +0200 From: Juergen Quittek To: Ganesh Sadasivan cc: knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology Message-ID: <66746005.1017704435@[192.168.102.32]> In-Reply-To: <3CA8A88F.A6D27750@cisco.com> References: <3CA8A88F.A6D27750@cisco.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Ganesh, --On 01 April 2002 10:35 -0800 Ganesh Sadasivan wrote: > > Hi Jurgene, Tanja, > > Juergen Quittek wrote: > >> Hi KC, >> >> Here is a revised version of the terminology for the >> architecture document (as promised in Minneapolis). >> Most of the changes result from discussions with Tanja. >> >> The definitions of IPFIX device, template, control >> stream and data stream are unchanged, although I am >> not yet completely satisfied with them. >> Further discussion on all terms seems to be ahead. >> >> Cheers, >> >> Juergen >> -- >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >> Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de >> >> Terminology >> >> * IP Traffic Flows >> A flow is defined as a set of packets passing an observation >> domain in the network during a certain time interval. All packets >> belonging to a particular flow have a set of common properties. >> Each property is defined as the result of applying a function to >> the values of: >> >> 1. one or more of packet header fields (eg. destination IP >> address) >> 2. one or more properties of the packet itself (eg. packet length) >> 3. one or more of fields derived from packet treatment (eg. AS >> number) >> >> A packet is defined to belong to a flow if it completely >> satisfies all the defined properties of the flow. > > The sentence "Each of the fields from 1., 2. and 3. are referred to > as keys. " (from the arch spec) seems to be omitted here. This is > required for introducing the definition of flow type. What I feel is > appropriate is to pick up the entire defintion including examples > from the data model doc and stick it here also. I removed it, because I did not clearly understand it (maybe my English is not good enough). Do you means each one IS a key, or they altogether ARE THE flow key? If you consider 'flow key' to be an important term, than I suggest giving it its own entry in the terminology section. >> >> This definition covers the range from a flow containing all >> packets observed at a network interface to a flow consisting of >> just a single packet between two applications with a specific >> sequence number. > > The range could be broader. A flow could contain all packets > observed at one or more network interfaces. Right! It may even be an aggregate of packets selected at different probes in the network. Let's change this phrase to "... range from a flow containing all packets observed at different probes distributed in a network to ..." >> Please note that the flow definition does not >> match a general application-level end-to-end stream. > > I am not sure I understand this? A flow "could" match a general > application-level end-to-end stream. But it is not restricted > to this only. Is there a need to mention these lines or do you think > the flow defintion is not clear enough? Well, initially I considered it to be clear enough without this statement. But then I learned that too many people (on the list and in private discussions) ignored this fact even after reading it. I guess the reason is that the term 'flow' is already around for some time, and if you are used to think about a flow as an application level flow it can be hard to work with a different definition. So, the idea behind the redundant 'reminder' is reduce the number of people mixing up the definitions. >> However, >> an application may derive properties of application-level >> streams by processing measured flow data. >> >> * Observation Point >> The observation point is a location in the network where IP >> packets can be observed. Examples are a line to which a probe >> is attached, a shared medium, such as an Ethernet-based LAN, >> a single port of a router, or the routing engine of a router. > > Why is "a set of interfaces (physical or logical) of a router" from the > arch. spec omitted? Aggregation of ports (like fast ether channels in > Cisco routers) is used very much in deployments. Isn't this rather an observation domain? >> >> >> * Observation Domain >> A single IP traffic flow may contain packets observed at several >> different observation points, for example at several ports of a >> line card or at different probes. The observation domain of a >> flow is the set of observation points at which the packets of >> this flow have been or might have been observed. The minimal >> observation domain contains just a single observation point. > > From the definition above , it would mean if R1 and R2 collect > {Src AS, dst AS} on their respective n/w interfaces I1 and I2, then > {I1, I2} would make up an observation domain!! Let me > try to explain what I had in mind on this defintion: > The flows collected from various observation points could be subjected > to a series of sampling and classification operation in some sequence. > This result could be combining flows collected at different observation > points. An example for this is: The raw flow (5-tuple) collected at > 2 observation points O1 and O2, when a furthur classification is done > to choose all the packets that match a certain destination address > would result in aggregation within the node (by node I mean a router > or a linecard which can be clearly identified as a network entity and > capable of doing such aggregation). You can aggregate flows beyond boundaries of a single device, for eample by aggregating flows measured by several probes at a concentrator (see figure from my other posting below). +---+ +---+ +---+ | E-+-> | E-+-> | E-+------------->---+ | | | | | | | | | +---+ +-+-----+ +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> | | | | | | | | | | +---+ +-+-----+ +-+-+ +-+-+ | O | | M | | E-+->---+ | | | | +---+ | | | | | | | M | +-+-+ | O | | M | | | | | | | +---+ | | | +-----+ | O | | O | | O | ->-+-C-E-+-> +---+ +---+ +---+ +-----+ Protocol Remote Concentrator Proxy Converter Observation > Observation domain consists of the set of observation points, the > metering processes, the part of maintenance of flow records (which > includes functions like aggregation) and choosing a criteria for > export. I see, I'm sorry for misunderstanding your definition of the observation domain. My naive idea of the word 'domain' was rather a topological one than a functional one. How do you think about distributed observation domains in case of concentrators? >> >> * Metering Process >> The metering process generates flow records. Input to the >> process are IP packets observed in an observation domain. The >> metering process consists of a set of functions that includes >> packet header capturing, timestamping, sampling, classifying, >> and maintaining flow records. >> >> Sampling and classifying may be performed repeatedly (with >> different parameters). The sampling function selects a subset >> of the received set of items (packet headers with timestamps or >> flow records) to be passed further to the classifying function. >> The sampling function may be trivial by passing all items, >> which is equivalent to applying no sampling at all. The >> classifying function maps its input to flows. There are two >> extreme classifying functions: one mapping each packet to >> different flows and one mapping all packets to the same flow. >> >> Maintenance of flow records may include creating new records, >> updating existing ones, computing flow statistics, deriving further >> flow properties, detecting flow expiration, passing flows record to >> the exporting process, and deleting flow records. > > Maintenance of flow record can be thought of as a function of > observation domain . One more functionality which is outside > the metering process is a selection criteria for export. Yes, my fault again. I did not consider a function to be a component of a domain. But anyway, how can we fit it into the functional IPFIX model? Starting with ObservationPoint(s) - MeteringProcess(es) - ExportingProcess abbreviated by O - M - E Now you define the observation domain (OD) as a set of some observation points and some metering processes. OD = O - M But you want it to also host some additional processes not in the first chain: maintaining flow records (MFR) and 'selection criteria for export' (SCE). Shall we now extend the original chain to O - M - MFR - SCE - E with OD = O - M - MFR - SCE? >> >> >> The figure below shows the sequence in which the functions are applied. >> >> packet header capturing >> | >> timestamping >> | >> v >> +----->+ >> | | >> | sampling >> | | >> | classifying >> | | >> +------+ >> | >> maintaining flow records >> | >> v >> >> Figure 1: Functions of the metering process >> >> * Flow Record >> A flow record contains information about a specific flow that was >> metered in an observation domain. A flow record contains measured >> properties of the flow (e.g. the total number of bytes of all packets >> of the flow) and usually characteristic properties of the flow (e.g. >> source IP address). >> >> * Exporting Process >> The exporting process sends flow records to one or more collectors. >> The flow records are generated by one or more metering processes. > > There could be an option export criteria at the observation domain which > chooses which records to export. Agreed. Juergen > Ganesh > >> >> >> * Collecting Process >> The collecting process receives flow records from one or more exporting >> processes. The collecting process might store received flow record >> or further process them, but these actions are out of the scope of >> this document. >> >> * IPFIX Device: >> A device hosting at least an observation point, a metering >> process and a flow information export process. Typically, >> corresponding observation point(s), metering process(es), and >> exporter process(es) are co-located at this device, for example, >> at a router. >> >> * Template: >> Templates is a set of {type, length} ordered pairs, used to >> completely identify the structure and semantics of a particular >> information that needs to be communicated from the IPFIX Device >> to the collector. Each template is uniquely identified by a >> Template ID. >> >> * Control Stream, Data Stream: >> The information that needs to be exported from the IPFIX device >> can be classified into the following categories: >> >> - Control Information : >> This includes the flow type definition, selection criteria >> for packets within the flow. This is also called as Control >> Stream. >> - Flow record : >> This includes data records corresponding to the various >> observed flows at each of the observation point. This is also >> called as Data Stream. >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Apr 2 07:36:07 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13205 for ; Tue, 2 Apr 2002 07:36:07 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16sN7l-0002gZ-00 for ipfix-list@mil.doit.wisc.edu; Tue, 02 Apr 2002 06:10:53 -0600 Received: from mailhub.xacct.com ([204.253.100.25]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16sN7i-0002fm-00 for ipfix-arch@net.doit.wisc.edu; Tue, 02 Apr 2002 06:10:50 -0600 Received: (qmail 7605 invoked from network); 2 Apr 2002 12:10:15 -0000 Received: from unknown (HELO usmail.xacct.com) (204.253.100.12) by mailhub.us.xacct.com with SMTP; 2 Apr 2002 12:10:15 -0000 Received: from Kevinz ([216.239.103.146]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g32C9vX22354; Tue, 2 Apr 2002 04:09:59 -0800 Reply-To: From: "kevin.zhang" To: "Juergen Quittek" Cc: Subject: RE: [ipfix-arch] revised terminology Date: Tue, 2 Apr 2002 07:09:59 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <12205450.1017371280@[192.168.102.31]> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id HAA13205 Hi Juergen, Please see my other comments inserted. Thanks, Kevin > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Juergen Quittek > Sent: Thursday, March 28, 2002 9:08 PM > To: knorseth@enterasys.com > Cc: ipfix-arch@net.doit.wisc.edu > Subject: [ipfix-arch] revised terminology > > > Hi KC, > > Here is a revised version of the terminology for the > architecture document (as promised in Minneapolis). > Most of the changes result from discussions with Tanja. > > The definitions of IPFIX device, template, control > stream and data stream are unchanged, although I am > not yet completely satisfied with them. > Further discussion on all terms seems to be ahead. > > Cheers, > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > Terminology > > * IP Traffic Flows > A flow is defined as a set of packets passing an observation > domain in the network during a certain time interval. All packets > belonging to a particular flow have a set of common properties. > Each property is defined as the result of applying a function to > the values of: > > 1. one or more of packet header fields (eg. destination IP > address) > 2. one or more properties of the packet itself (eg. packet length) > 3. one or more of fields derived from packet treatment (eg. AS > number) > > A packet is defined to belong to a flow if it completely > satisfies all the defined properties of the flow. > > This definition covers the range from a flow containing all > packets observed at a network interface to a flow consisting of > just a single packet between two applications with a specific > sequence number. Please note that the flow definition does not > match a general application-level end-to-end stream. However, > an application may derive properties of application-level > streams by processing measured flow data. > > * Observation Point > The observation point is a location in the network where IP > packets can be observed. Examples are a line to which a probe > is attached, a shared medium, such as an Ethernet-based LAN, > a single port of a router, or the routing engine of a router. > > * Observation Domain > A single IP traffic flow may contain packets observed at several > different observation points, for example at several ports of a > line card or at different probes. The observation domain of a > flow is the set of observation points at which the packets of > this flow have been or might have been observed. The minimal > observation domain contains just a single observation point. > > * Metering Process > The metering process generates flow records. Input to the > process are IP packets observed in an observation domain. The > metering process consists of a set of functions that includes > packet header capturing, timestamping, sampling, classifying, > and maintaining flow records. > > Sampling and classifying may be performed repeatedly (with > different parameters). The sampling function selects a subset > of the received set of items (packet headers with timestamps or > flow records) to be passed further to the classifying function. > The sampling function may be trivial by passing all items, > which is equivalent to applying no sampling at all. The > classifying function maps its input to flows. There are two > extreme classifying functions: one mapping each packet to > different flows and one mapping all packets to the same flow. > > Maintenance of flow records may include creating new records, > updating existing ones, computing flow statistics, deriving further > flow properties, detecting flow expiration, passing flows record to > the exporting process, and deleting flow records. > > The figure below shows the sequence in which the functions are applied. > > packet header capturing > | > timestamping > | > v > +----->+ > | | > | sampling > | | > | classifying > | | > +------+ > | > maintaining flow records > | > v > > Figure 1: Functions of the metering process > > > * Flow Record > A flow record contains information about a specific flow that was > metered in an observation domain. A flow record contains measured > properties of the flow (e.g. the total number of bytes of all packets > of the flow) and usually characteristic properties of the flow (e.g. > source IP address). > > * Exporting Process > The exporting process sends flow records to one or more collectors. > The flow records are generated by one or more metering processes. > > * Collecting Process > The collecting process receives flow records from one or more exporting > processes. The collecting process might store received flow record > or further process them, but these actions are out of the scope of > this document. > > * IPFIX Device: > A device hosting at least an observation point, a metering > process and a flow information export process. Typically, > corresponding observation point(s), metering process(es), and > exporter process(es) are co-located at this device, for example, > at a router. > > * Template: > Templates is a set of {type, length} ordered pairs, used to > completely identify the structure and semantics of a particular > information that needs to be communicated from the IPFIX Device > to the collector. Each template is uniquely identified by a > Template ID. > Template describes the data records exported, we don't need to constrain it to be (type, length) pairs in the requirement document. Different descriptors should be allowed e.g. (type, length)pair, it should be specified by the architecture document. I propose to change it to - *Template: Template is a set of ordered descriptors, used to completely specify the structure and semantics of a particular information that needs to be communicated from the IPFIX Device to the collector. Each template is uniquely identified by a Template ID. > * Control Stream, Data Stream: > The information that needs to be exported from the IPFIX device > can be classified into the following categories: > > - Control Information : > This includes the flow type definition, selection criteria > for packets within the flow. This is also called as Control > Stream. > - Flow record : > This includes data records corresponding to the various > observed flows at each of the observation point. This is also > called as Data Stream. > Based on our discussions in Minneapolis, the term "Control Stream" was not agreed upon. It appeared people like to use something else like "control information", and it is exchanged between IPFIX end points. My proposal is - *Control Information, Data Stream: The information that needs to be exchanged between IPFIX devices can be classified into the following categories: - Control Information: Control information is exchanged between IPFIX devices to facilitate flow record exporting. It includes the flow type definition, selection criteria for packets within the flow, and device capabilities. - Flow record: This includes data records corresponding to the various observed flows at each of the observation point. This is also called as Data Stream. > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ޖ[hfhzݢ++njwlk/zZyƠyI칻&ޙj:+vw""vvƲ칻&ފ,j܀bm*_ݢ++n܆+ From majordomo@mil.doit.wisc.edu Tue Apr 2 10:11:02 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18428 for ; Tue, 2 Apr 2002 10:11:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16sPZD-0006Fr-00 for ipfix-list@mil.doit.wisc.edu; Tue, 02 Apr 2002 08:47:23 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16sPZA-0006Es-00 for ipfix-arch@net.doit.wisc.edu; Tue, 02 Apr 2002 08:47:20 -0600 Received: from cisco.com (bclaise-isdn-home5.cisco.com [10.49.4.222]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA12986; Tue, 2 Apr 2002 16:46:04 +0200 (MET DST) Message-ID: <3CA9C429.8000809@cisco.com> Date: Tue, 02 Apr 2002 16:46:01 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: <12205450.1017371280@[192.168.102.31]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Juergen, Some comments. Note that some of them were already made by Ganesh. > Hi KC, > > Here is a revised version of the terminology for the > architecture document (as promised in Minneapolis). > Most of the changes result from discussions with Tanja. > > The definitions of IPFIX device, template, control > stream and data stream are unchanged, although I am > not yet completely satisfied with them. > Further discussion on all terms seems to be ahead. > > Cheers, > > Juergen Terminology * IP Traffic Flows A flow is defined as a set of packets passing an observation domain in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties. Each property is defined as the result of applying a function to the values of: You changed from passing an obervation point to an observation domain. I prefered observation point; it was more self-explaining. You define below the observation domain. But this term is already used in the architecture document for another purpose. * Observation Domain: The set of observation points which is the largest aggregatable set of flow information at the IPFIX Device is termed as an observation domain. The observation domain presents itself a unique ID to the collector for identifying the export packets generated by it. One or more Observation Domains can interface with the same export process. Example: The observation domain could be a router line-card, composed of several interfaces with each interface being an observation point. This is confusing. That's the reason why I would put: - move back to the definition containing "passing an observation point" - remove the observation domain from the requirement. - move back to the definition of the observation which contains "or a set of interfaces..." See my comments below 1. one or more of packet header fields (eg. destination IP address) 2. one or more properties of the packet itself (eg. packet length) 3. one or more of fields derived from packet treatment (eg. AS number) A packet is defined to belong to a flow if it completely satisfies all the defined properties of the flow. This definition covers the range from a flow containing all packets observed at a network interface to a flow consisting of just a single packet between two applications with a specific sequence number. Please note that the flow definition does not match a general application-level end-to-end stream. However, an application may derive properties of application-level streams by processing measured flow data. * Observation Point The observation point is a location in the network where IP packets can be observed. Examples are a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a single port of a router, or the routing engine of a router. Continuing with the same optic as above. We don't need the observation domain, but we need to previous definition of the "observation point" which containted "... Examples are a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router." * Observation Domain A single IP traffic flow may contain packets observed at several different observation points, for example at several ports of a line card or at different probes. The observation domain of a flow is the set of observation points at which the packets of this flow have been or might have been observed. The minimal observation domain contains just a single observation point. * Metering Process The metering process generates flow records. Input to the process are IP packets observed in an observation domain. The should be: "observed at the observation point" metering process consists of a set of functions that includes packet header capturing, timestamping, sampling, classifying, and maintaining flow records. Sampling and classifying may be performed repeatedly (with different parameters). The sampling function selects a subset of the received set of items (packet headers with timestamps or flow records) to be passed further to the classifying function. The sampling function may be trivial by passing all items, which is equivalent to applying no sampling at all. The classifying function maps its input to flows. There are two extreme classifying functions: one mapping each packet to different flows and one mapping all packets to the same flow. Maintenance of flow records may include creating new records, updating existing ones, computing flow statistics, deriving further flow properties, detecting flow expiration, passing flows record to the exporting process, and deleting flow records. The figure below shows the sequence in which the functions are applied. packet header capturing | timestamping | v +----->+ | | | sampling | | | classifying | | +------+ | maintaining flow records | v Figure 1: Functions of the metering process * Flow Record A flow record contains information about a specific flow that was metered in an observation domain. A flow record contains measured Again, observation domain -> obvservation point. This should be the same for all over. Regards, Benoit properties of the flow (e.g. the total number of bytes of all packets of the flow) and usually characteristic properties of the flow (e.g. source IP address). * Exporting Process The exporting process sends flow records to one or more collectors. The flow records are generated by one or more metering processes. * Collecting Process The collecting process receives flow records from one or more exporting processes. The collecting process might store received flow record or further process them, but these actions are out of the scope of this document. * IPFIX Device: A device hosting at least an observation point, a metering process and a flow information export process. Typically, corresponding observation point(s), metering process(es), and exporter process(es) are co-located at this device, for example, at a router. * Template: Templates is a set of {type, length} ordered pairs, used to completely identify the structure and semantics of a particular information that needs to be communicated from the IPFIX Device to the collector. Each template is uniquely identified by a Template ID. * Control Stream, Data Stream: The information that needs to be exported from the IPFIX device can be classified into the following categories: - Control Information : This includes the flow type definition, selection criteria for packets within the flow. This is also called as Control Stream. - Flow record : This includes data records corresponding to the various observed flows at each of the observation point. This is also called as Data Stream. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Apr 2 10:51:33 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19808 for ; Tue, 2 Apr 2002 10:51:33 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16sQL3-0007Oc-00 for ipfix-list@mil.doit.wisc.edu; Tue, 02 Apr 2002 09:36:49 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16sQL0-0007Ni-00 for ipfix-arch@net.doit.wisc.edu; Tue, 02 Apr 2002 09:36:46 -0600 Received: from cisco.com (bclaise-isdn-home5.cisco.com [10.49.4.222]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA13779; Tue, 2 Apr 2002 17:36:07 +0200 (MET DST) Message-ID: <3CA9CFE6.6080308@cisco.com> Date: Tue, 02 Apr 2002 17:36:06 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kevin.zhang@xacct.com CC: Juergen Quittek , ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit All, kevin.zhang wrote: > >> * Control Stream, Data Stream: >> The information that needs to be exported from the IPFIX device >> can be classified into the following categories: >> >> - Control Information : >> This includes the flow type definition, selection criteria >> for packets within the flow. This is also called as Control >> Stream. >> I would just say: - Control Information : This includes the flow type definition, selection criteria for packets within the flow and any other control messages. Regards, Benoit >> >> - Flow record : >> This includes data records corresponding to the various >> observed flows at each of the observation point. This is also >> called as Data Stream. >> >Based on our discussions in Minneapolis, the term "Control Stream" was not agreed upon. It appeared people like to use something else like "control information", and it is exchanged between IPFIX end points. My proposal is - > >*Control Information, Data Stream: >The information that needs to be exchanged between IPFIX devices can be classified into the following categories: > >- Control Information: >Control information is exchanged between IPFIX devices to facilitate flow record exporting. It includes the flow type definition, selection criteria for packets within the flow, and device capabilities. > >- Flow record: >This includes data records corresponding to the various observed flows at each of the observation point. This is also called as Data Stream. > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Apr 2 15:41:15 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02426 for ; Tue, 2 Apr 2002 15:41:15 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16sUYt-0005jk-00 for ipfix-list@mil.doit.wisc.edu; Tue, 02 Apr 2002 14:07:23 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16sUYr-0005in-00 for ipfix-arch@net.doit.wisc.edu; Tue, 02 Apr 2002 14:07:21 -0600 Received: from cisco.com (bclaise-isdn-home5.cisco.com [10.49.4.222]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA21487 for ; Tue, 2 Apr 2002 22:06:49 +0200 (MET DST) Message-ID: <3CAA0F59.4080503@cisco.com> Date: Tue, 02 Apr 2002 22:06:49 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] Feedback on the architecture draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit All, Some comments on the latest architecture version f: http://ipfix.doit.wisc.edu/arch/draft-ietf-ipfix-architecture-00f.txt Next to what has been decided in Minneapolis. 1. Terminology -------------- As we can see on the mailing list, the terminology is a big issue. I think there are too many places where we have a terminology section: the requirement, the architecture and the data model. To make sure that we are all speaking about the same terminology in the architecture and in the data model (based on the definitions from the requirement), in order to remove any references from the architecture to the data model and vice versa... in 2 words... to avoid confusion, I propose to: - add this note before the termonilogy sections of the architecture draft and the data model draft "Note that this terminology section contains the same definitions as in the terminology section of the [IPFIX-DATA] | [IPFIX-ARCHI]" - make all definitions redundant in both drafts. It just costs a cut-and-paste but it's a lot clearer - put the entire definition in both drafts. Ex: the IP traffic Flow should even contain the examples 2. Metering Process Functions ----------------------------- As I proposed in Minneapolis, the entire section 5 "Metering Process Functions" from the data model should be inserted under the section 4 "IPFIX reference model" from the architecture model: 4.1 Metering Process Functions 4.1.1 flow classification 4.1.2 selection criteria of packets 4.1.2.1 function on properties that determines a flow type (Fi) 4.1.2.2 sampling packets on a flow type (Si) 4.1.3 selection criteria of flows for export 4.1.4 flow expiration 3. IPFIX reference model ------------------------ The "optional metering process (flow level)" must be replaced by selection criteria of flow for export. Because this doesn't fit into the metering process definition: " The metering process generates flow records. Input to the process are IP packets observed ..." Then we need a new paragraph under the section 4, referencing the Si and Fi definition that we just added in the architecture draft (see point number 2). 4.2 Selection Criteria of flows for export The measurement device MAY define additional rules so that only certain flows records are picked up for export. This MAY be done by either one of the two types of methods defined in 4.1.2.1 and 4.1.2.2 or a combination of them. Example: The flow records which meets the following selection criteria are only exported. 1. All flow records whose destination IP address matches {20.3.1.5}. 2. Every other (.i.e sampling rate 1 in 2) flow record whose destination IP address matches {160.0.1.30}. 4. Collector ------------ In the section 4.4, we can read "The functions of the collector MAY include: * Identifying and accepting export packets from different (Export Process, Observation Domain) pairs" This last sentence should be changed to: "* Identifying, accepting and decoding export packets from different (Export Process, Observation Domain) pairs" Again in 4.4, the following chapter should be removed, as it's contained in 4.5 already " The application(s) and the collector may be tightly coupled in one system. They may also be logically or physically a separate subsystem from the application(s). In which case, the communication between them is beyond the scope of IPFIX. " 5. Table of Content ------------------- There is no chapter 5.4, while there is chapter 5.5 Plus some minor corrections (mostly typo's) that I forwarded directly to Ganesh. I won't bother the mailing list with details. Regards, Benoit -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Apr 2 16:53:58 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05045 for ; Tue, 2 Apr 2002 16:53:58 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16sVtU-0007aJ-00 for ipfix-list@mil.doit.wisc.edu; Tue, 02 Apr 2002 15:32:44 -0600 Received: from mailhub.xacct.com ([204.253.100.25]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16sVtS-0007a9-00 for ipfix-arch@net.doit.wisc.edu; Tue, 02 Apr 2002 15:32:42 -0600 Received: (qmail 17712 invoked from network); 2 Apr 2002 21:32:06 -0000 Received: from unknown (HELO usmail.xacct.com) (204.253.100.12) by mailhub.us.xacct.com with SMTP; 2 Apr 2002 21:32:05 -0000 Received: from Kevinz ([208.212.202.88]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g32LW0131288; Tue, 2 Apr 2002 13:32:01 -0800 Reply-To: From: "kevin.zhang" To: "Benoit Claise" Cc: "Juergen Quittek" , Subject: RE: [ipfix-arch] revised terminology Date: Tue, 2 Apr 2002 16:32:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3CA9CFE6.6080308@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id QAA05045 Hi Benoit, I would like to underscore the point that control information is bi-directional, especially now as TCP is selected as the transport protocol. Please let me know some specifics of my proposal that you don't like, I sure can revise my proposal. Thanks, Kevin > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Tuesday, April 02, 2002 10:36 AM > To: kevin.zhang@xacct.com > Cc: Juergen Quittek; ipfix-arch@net.doit.wisc.edu > Subject: Re: [ipfix-arch] revised terminology > > > All, > > kevin.zhang wrote: > > > > >> * Control Stream, Data Stream: > >> The information that needs to be exported from the IPFIX device > >> can be classified into the following categories: > >> > >> - Control Information : > >> This includes the flow type definition, selection criteria > >> for packets within the flow. This is also called as Control > >> Stream. > >> > I would just say: > - Control Information : > This includes the flow type definition, selection criteria > for packets within the flow and any other control messages. > > Regards, Benoit > > >> > >> - Flow record : > >> This includes data records corresponding to the various > >> observed flows at each of the observation point. This is also > >> called as Data Stream. > >> > >Based on our discussions in Minneapolis, the term "Control > Stream" was not agreed upon. It appeared people like to use > something else like "control information", and it is exchanged > between IPFIX end points. My proposal is - > > > >*Control Information, Data Stream: > >The information that needs to be exchanged between IPFIX devices > can be classified into the following categories: > > > >- Control Information: > >Control information is exchanged between IPFIX devices to > facilitate flow record exporting. It includes the flow type > definition, selection criteria for packets within the flow, and > device capabilities. > > > >- Flow record: > >This includes data records corresponding to the various observed > flows at each of the observation point. This is also called as > Data Stream. > > > ޖ[hfhzݢ++njwlk/zZyƠyI칻&ޙj:+vw""vvƲ칻&ފ,j܀bm*_ݢ++n܆+ From majordomo@mil.doit.wisc.edu Tue Apr 2 19:59:18 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10193 for ; Tue, 2 Apr 2002 19:59:18 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16sYni-0003j3-00 for ipfix-list@mil.doit.wisc.edu; Tue, 02 Apr 2002 18:38:58 -0600 Received: from c001-h000.c001.snv.cp.net ([209.228.32.114] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16sYnf-0003iq-00 for ipfix-arch@net.doit.wisc.edu; Tue, 02 Apr 2002 18:38:55 -0600 Received: (cpmta 27515 invoked from network); 2 Apr 2002 16:38:22 -0800 Received: from 24.221.253.53 (HELO kcn) by smtp.register-admin.com (209.228.32.114) with SMTP; 2 Apr 2002 16:38:22 -0800 X-Sent: 3 Apr 2002 00:38:22 GMT Message-ID: <001a01c1daa8$08eac8d0$850f880a@kcn> From: "K.C. Norseth" To: , "Benoit Claise" Cc: "Juergen Quittek" , References: Subject: Re: [ipfix-arch] revised terminology Date: Tue, 2 Apr 2002 17:39:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit Hi Kevin, Although I agree that bi-directional control information is very imporant, using TCP does not signify bi-directional control information. All it says it we have a link establish and can detect that the collector is alive. We have not even specified it has to be reliable TCP, the transport protocol must be congestion aware. SCTP has a congestion aware, unreliable transport mechanism available. The amount of control information is still up in the air. I do think that the chosen protocol should have bi-directional control information. The amount of bi-directional control is still to be decided. K.C. ----- Original Message ----- From: "kevin.zhang" To: "Benoit Claise" Cc: "Juergen Quittek" ; Sent: Tuesday, April 02, 2002 2:32 PM Subject: RE: [ipfix-arch] revised terminology | Hi Benoit, | | I would like to underscore the point that control information is bi-directional, especially now as TCP is selected as the transport protocol. Please let me know some specifics of my proposal that you don't like, I sure can revise my proposal. | | Thanks, | | Kevin | | > -----Original Message----- | > From: Benoit Claise [mailto:bclaise@cisco.com] | > Sent: Tuesday, April 02, 2002 10:36 AM | > To: kevin.zhang@xacct.com | > Cc: Juergen Quittek; ipfix-arch@net.doit.wisc.edu | > Subject: Re: [ipfix-arch] revised terminology | > | > | > All, | > | > kevin.zhang wrote: | > | > > | > >> * Control Stream, Data Stream: | > >> The information that needs to be exported from the IPFIX device | > >> can be classified into the following categories: | > >> | > >> - Control Information : | > >> This includes the flow type definition, selection criteria | > >> for packets within the flow. This is also called as Control | > >> Stream. | > >> | > I would just say: | > - Control Information : | > This includes the flow type definition, selection criteria | > for packets within the flow and any other control messages. | > | > Regards, Benoit | > | > >> | > >> - Flow record : | > >> This includes data records corresponding to the various | > >> observed flows at each of the observation point. This is also | > >> called as Data Stream. | > >> | > >Based on our discussions in Minneapolis, the term "Control | > Stream" was not agreed upon. It appeared people like to use | > something else like "control information", and it is exchanged | > between IPFIX end points. My proposal is - | > > | > >*Control Information, Data Stream: | > >The information that needs to be exchanged between IPFIX devices | > can be classified into the following categories: | > > | > >- Control Information: | > >Control information is exchanged between IPFIX devices to | > facilitate flow record exporting. It includes the flow type | > definition, selection criteria for packets within the flow, and | > device capabilities. | > > | > >- Flow record: | > >This includes data records corresponding to the various observed | > flows at each of the observation point. This is also called as | > Data Stream. | > > | > T?ZSjzSܱǹzZzgn?R{n?j)fs?ڷqjwk+rz*<TjܭȽYS- q?+ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Apr 3 01:25:19 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17316 for ; Wed, 3 Apr 2002 01:25:18 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16sdty-0002SQ-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Apr 2002 00:05:46 -0600 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16sdtw-0002Rk-00 for ipfix-arch@net.doit.wisc.edu; Wed, 03 Apr 2002 00:05:45 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g3365Eb20485; Tue, 2 Apr 2002 22:05:14 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-17.cisco.com [171.71.137.17]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABT55088; Tue, 2 Apr 2002 22:03:15 -0800 (PST) Message-ID: <3CAA9B02.B95DDA91@cisco.com> Date: Tue, 02 Apr 2002 22:02:43 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: <3CA8A88F.A6D27750@cisco.com> <66746005.1017704435@[192.168.102.32]> Content-Type: multipart/alternative; boundary="------------758A1831146257F6F4C68D6D" Precedence: bulk Sender: majordomo listserver --------------758A1831146257F6F4C68D6D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jurgen, Juergen Quittek wrote: > Hi Ganesh, > > --On 01 April 2002 10:35 -0800 Ganesh Sadasivan wrote: > > > > > Hi Jurgene, Tanja, > > > > Juergen Quittek wrote: > > > >> Hi KC, > >> > >> Here is a revised version of the terminology for the > >> architecture document (as promised in Minneapolis). > >> Most of the changes result from discussions with Tanja. > >> > >> The definitions of IPFIX device, template, control > >> stream and data stream are unchanged, although I am > >> not yet completely satisfied with them. > >> Further discussion on all terms seems to be ahead. > >> > >> Cheers, > >> > >> Juergen > >> -- > >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > >> Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > >> > >> Terminology > >> > >> * IP Traffic Flows > >> A flow is defined as a set of packets passing an observation > >> domain in the network during a certain time interval. All packets > >> belonging to a particular flow have a set of common properties. > >> Each property is defined as the result of applying a function to > >> the values of: > >> > >> 1. one or more of packet header fields (eg. destination IP > >> address) > >> 2. one or more properties of the packet itself (eg. packet length) > >> 3. one or more of fields derived from packet treatment (eg. AS > >> number) > >> > >> A packet is defined to belong to a flow if it completely > >> satisfies all the defined properties of the flow. > > > > The sentence "Each of the fields from 1., 2. and 3. are referred to > > as keys. " (from the arch spec) seems to be omitted here. This is > > required for introducing the definition of flow type. What I feel is > > appropriate is to pick up the entire defintion including examples > > from the data model doc and stick it here also. > > I removed it, because I did not clearly understand it (maybe my English > is not good enough). Do you means each one IS a key, or they altogether > ARE THE flow key? > > If you consider 'flow key' to be an important term, than I suggest > giving it its own entry in the terminology section. Each field is termed key or flow key . Yes we can add it as a term in the terminology. > > > >> > >> This definition covers the range from a flow containing all > >> packets observed at a network interface to a flow consisting of > >> just a single packet between two applications with a specific > >> sequence number. > > > > The range could be broader. A flow could contain all packets > > observed at one or more network interfaces. > > Right! It may even be an aggregate of packets selected at different > probes in the network. > > Let's change this phrase to "... range from a flow containing all > packets observed at different probes distributed in a network to ..." Just out of curiosity are there deploymens that use flows in such a manner for probes? > > > >> Please note that the flow definition does not > >> match a general application-level end-to-end stream. > > > > I am not sure I understand this? A flow "could" match a general > > application-level end-to-end stream. But it is not restricted > > to this only. Is there a need to mention these lines or do you think > > the flow defintion is not clear enough? > > Well, initially I considered it to be clear enough without this > statement. But then I learned that too many people (on the list > and in private discussions) ignored this fact even after reading > it. I guess the reason is that the term 'flow' is already around > for some time, and if you are used to think about a flow as an > application level flow it can be hard to work with a different > definition. > So, the idea behind the redundant 'reminder' is reduce the number > of people mixing up the definitions. Can we re-phrase the paragragh then to: Though a flow could match a general application-level end-to-end stream, it's defintion not restricted to this alone. > > > >> However, > >> an application may derive properties of application-level > >> streams by processing measured flow data. > >> > >> * Observation Point > >> The observation point is a location in the network where IP > >> packets can be observed. Examples are a line to which a probe > >> is attached, a shared medium, such as an Ethernet-based LAN, > >> a single port of a router, or the routing engine of a router. > > > > Why is "a set of interfaces (physical or logical) of a router" from the > > arch. spec omitted? Aggregation of ports (like fast ether channels in > > Cisco routers) is used very much in deployments. > > Isn't this rather an observation domain? No. Atleast on a router (I'm not sure about probes) we can group a set of ports , say 5 fast ethernet ports to form a "port channel" . This interface from a L3 perspective for any traffic coming on these 5 fast ethernets is the "port channel". Similarly a tunnel interface (GRE) can span over multiple physical interfaces. > > > >> > >> > >> * Observation Domain > >> A single IP traffic flow may contain packets observed at several > >> different observation points, for example at several ports of a > >> line card or at different probes. The observation domain of a > >> flow is the set of observation points at which the packets of > >> this flow have been or might have been observed. The minimal > >> observation domain contains just a single observation point. > > > > From the definition above , it would mean if R1 and R2 collect > > {Src AS, dst AS} on their respective n/w interfaces I1 and I2, then > > {I1, I2} would make up an observation domain!! Let me > > try to explain what I had in mind on this defintion: > > The flows collected from various observation points could be subjected > > to a series of sampling and classification operation in some sequence. > > This result could be combining flows collected at different observation > > points. An example for this is: The raw flow (5-tuple) collected at > > 2 observation points O1 and O2, when a furthur classification is done > > to choose all the packets that match a certain destination address > > would result in aggregation within the node (by node I mean a router > > or a linecard which can be clearly identified as a network entity and > > capable of doing such aggregation). > > You can aggregate flows beyond boundaries of a single device, > for eample by aggregating flows measured by several probes at > a concentrator (see figure from my other posting below). > > +---+ +---+ +---+ > | E-+-> | E-+-> | E-+------------->---+ > | | | | | | | | | +---+ +-+-----+ > +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> > | | | | | | | | | | +---+ +-+-----+ > +-+-+ +-+-+ | O | | M | | E-+->---+ > | | | | +---+ | | | | | | > | M | +-+-+ | O | | M | > | | | | | | +---+ | | | +-----+ > | O | | O | | O | ->-+-C-E-+-> > +---+ +---+ +---+ +-----+ > > Protocol Remote Concentrator Proxy > Converter Observation What is the input to concentrator? Is it IPFIX flow records or packets itself? For Protocol converter, remote observation, OD = O - M - MFR - SCE fits in well. For the concetrator case I am not sure what C-M-E do. If you can explain furthur then we can find out. Same is the case with proxy - what is the input to it? Thanks Ganesh > > > > Observation domain consists of the set of observation points, the > > metering processes, the part of maintenance of flow records (which > > includes functions like aggregation) and choosing a criteria for > > export. > > I see, I'm sorry for misunderstanding your definition of the > observation domain. My naive idea of the word 'domain' was > rather a topological one than a functional one. > > How do you think about distributed observation domains in case > of concentrators? > > >> > >> * Metering Process > >> The metering process generates flow records. Input to the > >> process are IP packets observed in an observation domain. The > >> metering process consists of a set of functions that includes > >> packet header capturing, timestamping, sampling, classifying, > >> and maintaining flow records. > >> > >> Sampling and classifying may be performed repeatedly (with > >> different parameters). The sampling function selects a subset > >> of the received set of items (packet headers with timestamps or > >> flow records) to be passed further to the classifying function. > >> The sampling function may be trivial by passing all items, > >> which is equivalent to applying no sampling at all. The > >> classifying function maps its input to flows. There are two > >> extreme classifying functions: one mapping each packet to > >> different flows and one mapping all packets to the same flow. > >> > >> Maintenance of flow records may include creating new records, > >> updating existing ones, computing flow statistics, deriving further > >> flow properties, detecting flow expiration, passing flows record to > >> the exporting process, and deleting flow records. > > > > Maintenance of flow record can be thought of as a function of > > observation domain . One more functionality which is outside > > the metering process is a selection criteria for export. > > Yes, my fault again. I did not consider a function to be a > component of a domain. > > But anyway, how can we fit it into the functional IPFIX model? > > Starting with > > ObservationPoint(s) - MeteringProcess(es) - ExportingProcess > > abbreviated by > > O - M - E > > Now you define the observation domain (OD) as a set of > some observation points and some metering processes. > > OD = O - M > > But you want it to also host some additional processes > not in the first chain: maintaining flow records (MFR) > and 'selection criteria for export' (SCE). > > Shall we now extend the original chain to > > O - M - MFR - SCE - E with OD = O - M - MFR - SCE? > > >> > >> > >> The figure below shows the sequence in which the functions are applied. > >> > >> packet header capturing > >> | > >> timestamping > >> | > >> v > >> +----->+ > >> | | > >> | sampling > >> | | > >> | classifying > >> | | > >> +------+ > >> | > >> maintaining flow records > >> | > >> v > >> > >> Figure 1: Functions of the metering process > >> > >> * Flow Record > >> A flow record contains information about a specific flow that was > >> metered in an observation domain. A flow record contains measured > >> properties of the flow (e.g. the total number of bytes of all packets > >> of the flow) and usually characteristic properties of the flow (e.g. > >> source IP address). > >> > >> * Exporting Process > >> The exporting process sends flow records to one or more collectors. > >> The flow records are generated by one or more metering processes. > > > > There could be an option export criteria at the observation domain which > > chooses which records to export. > > Agreed. > > Juergen > > > Ganesh --------------758A1831146257F6F4C68D6D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jurgen,

Juergen Quittek wrote:

Hi Ganesh,

--On 01 April 2002 10:35 -0800 Ganesh Sadasivan <gsadasiv@cisco.com> wrote:

>
> Hi Jurgene, Tanja,
>
> Juergen Quittek wrote:
>
>> Hi KC,
>>
>> Here is a revised version of the terminology for the
>> architecture document (as promised in Minneapolis).
>> Most of the changes result from discussions with Tanja.
>>
>> The definitions of IPFIX device, template, control
>> stream and data stream are unchanged, although I am
>> not yet completely satisfied with them.
>> Further discussion on all terms seems to be ahead.
>>
>> Cheers,
>>
>>     Juergen
>> --
>> Juergen Quittek     quittek@ccrle.nec.de     Tel: +49 6221 90511-15
>> NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
>> Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
>>
>> Terminology
>>
>>  * IP Traffic Flows
>>    A flow is defined as a set of packets passing an observation
>>    domain in the network during a certain time interval. All packets
>>    belonging to a particular flow have a set of common properties.
>>    Each property is defined as the result of applying a function to
>>    the values of:
>>
>>       1. one or more of packet header fields (eg. destination IP
>>          address)
>>       2. one or more properties of the packet itself (eg. packet length)
>>       3. one or more of fields derived from packet treatment (eg. AS
>>          number)
>>
>>    A packet is defined to belong to a flow if it completely
>>    satisfies all the defined properties of the flow.
>
> The sentence "Each of the fields from 1., 2. and 3. are referred to
> as keys.  " (from the arch spec) seems to be omitted here. This is
> required for introducing the definition of flow type. What I feel is
> appropriate is to pick up the entire defintion including examples
> from the data model doc and stick it here also.

I removed it, because I did not clearly understand it (maybe my English
is not good enough). Do you means each one IS a key, or they altogether
ARE THE flow key?

If you consider 'flow key' to be an important term, than I suggest
giving it its own entry in the terminology section.

Each field is termed key or flow key . Yes we can add it as a term
in the terminology.
 

>>
>>    This definition covers the range from a flow containing all
>>    packets observed at a network interface to a flow consisting of
>>    just a single packet between two applications with a specific
>>    sequence number.
>
> The range could be broader. A flow could contain all packets
> observed at one or more network interfaces.

Right! It may even be an aggregate of packets selected at different
probes in the network.

Let's change this phrase to "... range from a flow containing all
packets observed at different probes distributed in a network to ..."

 Just out of curiosity are there deploymens that use flows in such
a manner for probes?
 

>> Please note that the flow definition does not
>>    match a general application-level end-to-end stream.
>
> I am not sure I understand this? A flow "could" match a general
> application-level end-to-end stream. But it is not restricted
> to this only. Is there a need to mention these lines or do you think
> the flow defintion is not clear enough?

Well, initially I considered it to be clear enough without this
statement. But then I learned that too many people (on the list
and in private discussions) ignored this fact even after reading
it. I guess the reason is that the term 'flow' is already around
for some time, and if you are used to think about a flow as an
application level flow it can be hard to work with a different
definition.
So, the idea behind the redundant 'reminder' is reduce the number
of people mixing up the definitions.

Can we re-phrase the paragragh then to:
Though a  flow could match a general application-level end-to-end
stream, it's defintion not restricted to this alone.
 

>> However,
>>    an application may derive properties of application-level
>>    streams by processing measured flow data.
>>
>>  * Observation Point
>>    The observation point is a location in the network where IP
>>    packets can be observed. Examples are a line to which a probe
>>    is attached, a shared medium, such as an Ethernet-based LAN,
>>    a single port of a router, or the routing engine of a router.
>
> Why is "a set of interfaces (physical or logical) of a router"  from the
> arch. spec omitted? Aggregation of ports (like fast ether channels in
> Cisco routers) is used very much in deployments.

Isn't this rather an observation domain?

No. Atleast on a router (I'm not sure about probes) we can group a
set of ports , say 5 fast ethernet ports to form a "port channel" . This
 interface from a L3 perspective for any traffic coming on these
5 fast ethernets is the "port channel". Similarly a tunnel interface (GRE)
can span over multiple physical interfaces.
 

>>
>>
>>  * Observation Domain
>>    A single IP traffic flow may contain packets observed at several
>>    different observation points, for example at several ports of a
>>    line card or at different probes. The observation domain of a
>>    flow is the set of observation points at which the packets of
>>    this flow have been or might have been observed. The minimal
>>    observation domain contains just a single observation point.
>
> From the definition above , it  would mean if R1 and R2 collect
> {Src AS, dst AS} on their respective n/w interfaces  I1 and I2, then
> {I1, I2} would make up an observation domain!! Let me
> try to explain what I had in mind on this defintion:
> The flows collected from various observation points could be subjected
> to a series of sampling and classification operation in some sequence.
> This result could be combining flows collected at different observation
> points. An example for this is: The raw flow (5-tuple) collected at
> 2 observation points O1 and O2, when a furthur classification is done
> to choose all the packets that match a certain destination address
> would result in aggregation within the node (by node I mean a router
> or a linecard which can be clearly identified as a network entity and
> capable of doing such aggregation).

You can aggregate flows beyond boundaries of a single device,
for eample by aggregating flows measured by several probes at
a concentrator (see figure from my other posting below).

       +---+     +---+     +---+
       | E-+->   | E-+->   | E-+------------->---+
       | | |     | | |     | | | +---+         +-+-----+
       +-+-+     | M |     | M | | E-+------->-+-C-M-E-+->
         |       | | |     | | | | | | +---+   +-+-----+
       +-+-+     +-+-+     | O | | M | | E-+->---+
       | | |       |       +---+ | | | | | |
       | M |     +-+-+           | O | | M |
       | | |     | | |           +---+ | | |           +-----+
       | O |     | O |                 | O |        ->-+-C-E-+->
       +---+     +---+                 +---+           +-----+

      Protocol   Remote             Concentrator        Proxy
      Converter  Observation

What is the input to concentrator? Is it  IPFIX flow records or packets itself?
For Protocol converter, remote observation, OD = O - M - MFR - SCE fits
in well. For the concetrator case I am not sure what C-M-E do. If you can explain
furthur then we can find out. Same is the case with proxy - what is the input to it?

Thanks
Ganesh

 

> Observation domain consists of the set of observation points, the
> metering processes, the part of maintenance of flow records (which
> includes functions like aggregation) and  choosing a criteria  for
> export.

I see, I'm sorry for misunderstanding your definition of the
observation domain. My naive idea of the word 'domain' was
rather a topological one than a functional one.

How do you think about distributed observation domains in case
of concentrators?

>>
>>  * Metering Process
>>    The metering process generates flow records. Input to the
>>    process are IP packets observed in an observation domain. The
>>    metering process consists of a set of functions that includes
>>    packet header capturing, timestamping, sampling, classifying,
>>    and maintaining flow records.
>>
>>    Sampling and classifying may be performed repeatedly (with
>>    different parameters). The sampling function selects a subset
>>    of the received set of items (packet headers with timestamps or
>>    flow records) to be passed further to the classifying function.
>>    The sampling function may be trivial by passing all items,
>>    which is equivalent to applying no sampling at all. The
>>    classifying function maps its input to flows. There are two
>>    extreme classifying functions: one mapping each packet to
>>    different flows and one mapping all packets to the same flow.
>>
>>    Maintenance of flow records may include creating new records,
>>    updating existing ones, computing flow statistics, deriving further
>>    flow properties, detecting flow expiration, passing flows record to
>>    the exporting process, and deleting flow records.
>
> Maintenance of flow record can be thought of as a function of
> observation domain . One more functionality which is outside
> the metering process is a selection criteria for export.

Yes, my fault again. I did not consider a function to be a
component of a domain.

But anyway, how can we fit it into the functional IPFIX model?

Starting with

    ObservationPoint(s) - MeteringProcess(es) - ExportingProcess

abbreviated by

    O - M - E

Now you define the observation domain (OD) as a set of
some observation points and some metering processes.

    OD = O - M

But you want it to also host some additional processes
not in the first chain: maintaining flow records (MFR)
and 'selection criteria for export' (SCE).

Shall we now extend the original chain to

   O - M - MFR - SCE - E      with      OD = O - M - MFR - SCE?

>>
>>
>>    The figure below shows the sequence in which the functions are applied.
>>
>>                         packet header capturing
>>                                   |
>>                              timestamping
>>                                   |
>>                                   v
>>                            +----->+
>>                            |      |
>>                            |   sampling
>>                            |      |
>>                            | classifying
>>                            |      |
>>                            +------+
>>                                   |
>>                        maintaining flow records
>>                                   |
>>                                   v
>>
>>               Figure 1: Functions of the metering process
>>
>>  * Flow Record
>>    A flow record contains information about a specific flow that was
>>    metered in an observation domain. A flow record contains measured
>>    properties of the flow (e.g. the total number of bytes of all packets
>>    of the flow) and usually characteristic properties of the flow (e.g.
>>    source IP address).
>>
>>  * Exporting Process
>>    The exporting process sends flow records to one or more collectors.
>>    The flow records are generated by one or more metering processes.
>
> There could be an option export criteria at the observation domain which
> chooses which records to export.

Agreed.

    Juergen

> Ganesh

--------------758A1831146257F6F4C68D6D-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Apr 3 01:40:41 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17607 for ; Wed, 3 Apr 2002 01:40:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16seAM-0002ns-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Apr 2002 00:22:42 -0600 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16seAK-0002nJ-00 for ipfix-arch@net.doit.wisc.edu; Wed, 03 Apr 2002 00:22:40 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g336Lvl28024; Tue, 2 Apr 2002 22:21:57 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-17.cisco.com [171.71.137.17]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABT55324; Tue, 2 Apr 2002 22:20:11 -0800 (PST) Message-ID: <3CAA9EFA.B4EDC24E@cisco.com> Date: Tue, 02 Apr 2002 22:19:38 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: <12205450.1017371280@[192.168.102.31]> <3CA9C429.8000809@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit, I guess there was a confusion about the term "observation domain". Jurgene thought it was meant to convey a collection of observation points. Ganesh Benoit Claise wrote: > Hi Juergen, > > Some comments. > Note that some of them were already made by Ganesh. > > > Hi KC, > > > > Here is a revised version of the terminology for the > > architecture document (as promised in Minneapolis). > > Most of the changes result from discussions with Tanja. > > > > The definitions of IPFIX device, template, control > > stream and data stream are unchanged, although I am > > not yet completely satisfied with them. > > Further discussion on all terms seems to be ahead. > > > > Cheers, > > > > Juergen > > Terminology > > * IP Traffic Flows > A flow is defined as a set of packets passing an observation > domain in the network during a certain time interval. All packets > belonging to a particular flow have a set of common properties. > Each property is defined as the result of applying a function to > the values of: > > You changed from passing an obervation point to an observation domain. > I prefered observation point; it was more self-explaining. > You define below the observation domain. But this term is already used > in the architecture document for another purpose. > * Observation Domain: > The set of observation points which is the largest aggregatable > set of flow information at the IPFIX Device is termed as an > observation domain. The observation domain presents itself a > unique ID to the collector for identifying the export packets > generated by it. One or more Observation Domains can interface > with the same export process. Example: The observation domain > could be a router line-card, composed of several interfaces with > each interface being an observation point. > > This is confusing. That's the reason why I would put: > - move back to the definition containing "passing an observation point" > - remove the observation domain from the requirement. > - move back to the definition of the observation which contains "or a > set of interfaces..." See my comments below > > 1. one or more of packet header fields (eg. destination IP > address) > 2. one or more properties of the packet itself (eg. packet length) > 3. one or more of fields derived from packet treatment (eg. AS > number) > > A packet is defined to belong to a flow if it completely > satisfies all the defined properties of the flow. > > This definition covers the range from a flow containing all > packets observed at a network interface to a flow consisting of > just a single packet between two applications with a specific > sequence number. Please note that the flow definition does not > match a general application-level end-to-end stream. However, > an application may derive properties of application-level > streams by processing measured flow data. > > * Observation Point > The observation point is a location in the network where IP > packets can be observed. Examples are a line to which a probe > is attached, a shared medium, such as an Ethernet-based LAN, > a single port of a router, or the routing engine of a router. > > Continuing with the same optic as above. We don't need the observation > domain, but we need to previous definition of the "observation point" > which containted "... Examples are a line to which a probe is attached, > a shared medium, such as an Ethernet-based LAN, a single port of a > router, or a set of interfaces (physical or logical) of a router." > > * Observation Domain > A single IP traffic flow may contain packets observed at several > different observation points, for example at several ports of a > line card or at different probes. The observation domain of a > flow is the set of observation points at which the packets of > this flow have been or might have been observed. The minimal > observation domain contains just a single observation point. > > * Metering Process > The metering process generates flow records. Input to the > process are IP packets observed in an observation domain. The > > should be: "observed at the observation point" > > metering process consists of a set of functions that includes > packet header capturing, timestamping, sampling, classifying, > and maintaining flow records. > > Sampling and classifying may be performed repeatedly (with > different parameters). The sampling function selects a subset > of the received set of items (packet headers with timestamps or > flow records) to be passed further to the classifying function. > The sampling function may be trivial by passing all items, > which is equivalent to applying no sampling at all. The > classifying function maps its input to flows. There are two > extreme classifying functions: one mapping each packet to > different flows and one mapping all packets to the same flow. > > Maintenance of flow records may include creating new records, > updating existing ones, computing flow statistics, deriving further > flow properties, detecting flow expiration, passing flows record to > the exporting process, and deleting flow records. > > The figure below shows the sequence in which the functions are > applied. > > packet header capturing > | > timestamping > | > v > +----->+ > | | > | sampling > | | > | classifying > | | > +------+ > | > maintaining flow records > | > v > > Figure 1: Functions of the metering process > > * Flow Record > A flow record contains information about a specific flow that was > metered in an observation domain. A flow record contains measured > > Again, observation domain -> obvservation point. > This should be the same for all over. > > Regards, Benoit > > properties of the flow (e.g. the total number of bytes of all packets > of the flow) and usually characteristic properties of the flow (e.g. > source IP address). > > * Exporting Process > The exporting process sends flow records to one or more collectors. > The flow records are generated by one or more metering processes. > > * Collecting Process > The collecting process receives flow records from one or more > exporting > processes. The collecting process might store received flow record > or further process them, but these actions are out of the scope of > this document. > > * IPFIX Device: > A device hosting at least an observation point, a metering > process and a flow information export process. Typically, > corresponding observation point(s), metering process(es), and > exporter process(es) are co-located at this device, for example, > at a router. > > * Template: > Templates is a set of {type, length} ordered pairs, used to > completely identify the structure and semantics of a particular > information that needs to be communicated from the IPFIX Device > to the collector. Each template is uniquely identified by a > Template ID. > > * Control Stream, Data Stream: > The information that needs to be exported from the IPFIX device > can be classified into the following categories: > > - Control Information : > This includes the flow type definition, selection criteria > for packets within the flow. This is also called as Control > Stream. > - Flow record : > This includes data records corresponding to the various > observed flows at each of the observation point. This is also > called as Data Stream. > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Apr 3 08:48:43 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03103 for ; Wed, 3 Apr 2002 08:48:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ski3-00060L-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Apr 2002 07:21:55 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ski0-0005zg-00 for ipfix-arch@net.doit.wisc.edu; Wed, 03 Apr 2002 07:21:52 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g33DLL867220; Wed, 3 Apr 2002 15:21:21 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA23122; Wed, 3 Apr 2002 15:21:08 +0200 Date: Wed, 03 Apr 2002 15:24:19 +0200 From: Juergen Quittek To: Benoit Claise cc: ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology Message-ID: <19842932.1017847459@[192.168.102.164]> In-Reply-To: <3CA9C429.8000809@cisco.com> References: <3CA9C429.8000809@cisco.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, I already explained to Ganesh that I misunderstood your definition of observation domain, mainly because I did consider a domain a topological entity, not a functional one and therefore just interpreted it as a set of observation points without the metering function and others inside. Now I understand your definiton. My idea ws re-using your defintion, not overwriting it. What I wanted to cover is the situation that a metering process may merge packets observed at several different observation points into one flow. Then it doea not make sense to define a flow as a set of packets observed at a single observation point, but potentially also as a set of observation points, which I unfortunately called observation domain. Let's call it Set Of Oberservation Points (SOOP) for the rest of this message. As far as I understand, the SOOP is part of an observation domain. Consequently, my proposal is to define a flow to be a set of packets observed at a SOOP, not just at a single observation point. Of course a SOOP may contain a single observation point only. Juergen --On 02 April 2002 16:46 +0200 Benoit Claise wrote: > Hi Juergen, > > Some comments. > Note that some of them were already made by Ganesh. > >> Hi KC, >> >> Here is a revised version of the terminology for the >> architecture document (as promised in Minneapolis). >> Most of the changes result from discussions with Tanja. >> >> The definitions of IPFIX device, template, control >> stream and data stream are unchanged, although I am >> not yet completely satisfied with them. >> Further discussion on all terms seems to be ahead. >> >> Cheers, >> >> Juergen > > > Terminology > > * IP Traffic Flows > A flow is defined as a set of packets passing an observation > domain in the network during a certain time interval. All packets > belonging to a particular flow have a set of common properties. > Each property is defined as the result of applying a function to > the values of: > > You changed from passing an obervation point to an observation domain. > I prefered observation point; it was more self-explaining. > You define below the observation domain. But this term is already used in the architecture document for another purpose. > * Observation Domain: > The set of observation points which is the largest aggregatable > set of flow information at the IPFIX Device is termed as an > observation domain. The observation domain presents itself a > unique ID to the collector for identifying the export packets > generated by it. One or more Observation Domains can interface > with the same export process. Example: The observation domain > could be a router line-card, composed of several interfaces with > each interface being an observation point. > > This is confusing. That's the reason why I would put: > - move back to the definition containing "passing an observation point" > - remove the observation domain from the requirement. > - move back to the definition of the observation which contains "or a set of interfaces..." See my comments below > > 1. one or more of packet header fields (eg. destination IP > address) > 2. one or more properties of the packet itself (eg. packet length) > 3. one or more of fields derived from packet treatment (eg. AS > number) > > A packet is defined to belong to a flow if it completely > satisfies all the defined properties of the flow. > > This definition covers the range from a flow containing all > packets observed at a network interface to a flow consisting of > just a single packet between two applications with a specific > sequence number. Please note that the flow definition does not > match a general application-level end-to-end stream. However, > an application may derive properties of application-level > streams by processing measured flow data. > > * Observation Point > The observation point is a location in the network where IP > packets can be observed. Examples are a line to which a probe > is attached, a shared medium, such as an Ethernet-based LAN, > a single port of a router, or the routing engine of a router. > > Continuing with the same optic as above. We don't need the observation domain, but we need to previous definition of the "observation point" which containted "... Examples are a line to which a probe is attached, a shared medium, such as an > Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router." > > > * Observation Domain > A single IP traffic flow may contain packets observed at several > different observation points, for example at several ports of a > line card or at different probes. The observation domain of a > flow is the set of observation points at which the packets of > this flow have been or might have been observed. The minimal > observation domain contains just a single observation point. > > * Metering Process > The metering process generates flow records. Input to the > process are IP packets observed in an observation domain. The > > should be: "observed at the observation point" > > metering process consists of a set of functions that includes > packet header capturing, timestamping, sampling, classifying, > and maintaining flow records. > > Sampling and classifying may be performed repeatedly (with > different parameters). The sampling function selects a subset > of the received set of items (packet headers with timestamps or > flow records) to be passed further to the classifying function. > The sampling function may be trivial by passing all items, > which is equivalent to applying no sampling at all. The > classifying function maps its input to flows. There are two > extreme classifying functions: one mapping each packet to > different flows and one mapping all packets to the same flow. > > Maintenance of flow records may include creating new records, > updating existing ones, computing flow statistics, deriving further > flow properties, detecting flow expiration, passing flows record to > the exporting process, and deleting flow records. > > The figure below shows the sequence in which the functions are > applied. > > packet header capturing > | > timestamping > | > v > +----->+ > | | > | sampling > | | > | classifying > | | > +------+ > | > maintaining flow records > | > v > > Figure 1: Functions of the metering process > > > * Flow Record > A flow record contains information about a specific flow that was > metered in an observation domain. A flow record contains measured > > Again, observation domain -> obvservation point. > This should be the same for all over. > > Regards, Benoit > > properties of the flow (e.g. the total number of bytes of all packets > of the flow) and usually characteristic properties of the flow (e.g. > source IP address). > > * Exporting Process > The exporting process sends flow records to one or more collectors. > The flow records are generated by one or more metering processes. > > * Collecting Process > The collecting process receives flow records from one or more > exporting > processes. The collecting process might store received flow record > or further process them, but these actions are out of the scope of > this document. > > * IPFIX Device: > A device hosting at least an observation point, a metering > process and a flow information export process. Typically, > corresponding observation point(s), metering process(es), and > exporter process(es) are co-located at this device, for example, > at a router. > > * Template: > Templates is a set of {type, length} ordered pairs, used to > completely identify the structure and semantics of a particular > information that needs to be communicated from the IPFIX Device > to the collector. Each template is uniquely identified by a > Template ID. > > * Control Stream, Data Stream: > The information that needs to be exported from the IPFIX device > can be classified into the following categories: > > - Control Information : > This includes the flow type definition, selection criteria > for packets within the flow. This is also called as Control > Stream. > - Flow record : > This includes data records corresponding to the various > observed flows at each of the observation point. This is also > called as Data Stream. > > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Apr 3 08:54:48 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03237 for ; Wed, 3 Apr 2002 08:54:48 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16sksA-0006D3-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Apr 2002 07:32:22 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16sks7-0006CQ-00 for ipfix@net.doit.wisc.edu; Wed, 03 Apr 2002 07:32:20 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g33DVm867835; Wed, 3 Apr 2002 15:31:48 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA23234; Wed, 3 Apr 2002 15:31:36 +0200 Date: Wed, 03 Apr 2002 15:34:47 +0200 From: Juergen Quittek To: Benoit Claise , ipfix@net.doit.wisc.edu Subject: [ipfix] Where to define the metering process; was: Re: [ipfix-arch] Feedback on the architecture draft Message-ID: <20470925.1017848087@[192.168.102.164]> In-Reply-To: <3CAA0F59.4080503@cisco.com> References: <3CAA0F59.4080503@cisco.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit --On 02 April 2002 22:06 +0200 Benoit Claise wrote: > [...] > > 2. Metering Process Functions > ----------------------------- > As I proposed in Minneapolis, the entire section 5 "Metering Process Functions" from the data model should be inserted under the section 4 "IPFIX reference model" from the architecture model: > 4.1 Metering Process Functions > 4.1.1 flow classification > 4.1.2 selection criteria of packets > 4.1.2.1 function on properties that determines a flow type (Fi) > 4.1.2.2 sampling packets on a flow type (Si) > 4.1.3 selection criteria of flows for export > 4.1.4 flow expiration I completely agree that the metering process belongs to the architecture document. What functions and capability the metering process has are architectural issues, not information model issues. The architecture documents would be incomplete without a discussion of the metering process. Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Apr 3 09:10:58 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03712 for ; Wed, 3 Apr 2002 09:10:58 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16sky0-0006KF-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Apr 2002 07:38:24 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16skxy-0006I6-00 for ipfix@net.doit.wisc.edu; Wed, 03 Apr 2002 07:38:23 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g33Dbp868110 for ; Wed, 3 Apr 2002 15:37:51 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA23280 for ; Wed, 3 Apr 2002 15:37:39 +0200 Date: Wed, 03 Apr 2002 15:40:50 +0200 From: Juergen Quittek To: ipfix@net.doit.wisc.edu Subject: [ipfix] data-model doc: uni-/bi-directional flows Message-ID: <20833967.1017848450@[192.168.102.164]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all, I have a comment on section 4.2 of the data model document: 4.2. Unidirectional and Bidirectional Flows A flow defined by the above terms is unidirectional. In case the exporter has got the knowledge of the bi-directional flows and in case the bi-directional information make sense, the exporter MAY choose to export in the same Template/Flow Record, along with bidirectional accounting information. This would save some bandwidth as the exporter won't have to send two unidirectional flow records. I think the first sentence is wrong. I cannot see why our flow defintion does imply a flow to be uni-directional. All examples given in the data-model document are uni-directional flows, but this does not say the defintion excludes bi-directional ones. Can anyone explain me, why our flows are uni-directional? Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Apr 3 09:29:46 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04198 for ; Wed, 3 Apr 2002 09:29:45 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16slLy-0006xc-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Apr 2002 08:03:10 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16slLw-0006wy-00 for ipfix-arch@net.doit.wisc.edu; Wed, 03 Apr 2002 08:03:08 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g33E2b869397; Wed, 3 Apr 2002 16:02:37 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA23553; Wed, 3 Apr 2002 16:02:24 +0200 Date: Wed, 03 Apr 2002 16:05:35 +0200 From: Juergen Quittek To: Ganesh Sadasivan cc: knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology Message-ID: <22319443.1017849935@[192.168.102.164]> In-Reply-To: <3CAA9B02.B95DDA91@cisco.com> References: <3CAA9B02.B95DDA91@cisco.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit --On 02 April 2002 22:02 -0800 Ganesh Sadasivan wrote: > Hi Jurgen, > [...] >> >> The sentence "Each of the fields from 1., 2. and 3. are referred to >> as keys. " (from the arch spec) seems to be omitted here. This is >> required for introducing the definition of flow type. What I feel is >> appropriate is to pick up the entire defintion including examples >> from the data model doc and stick it here also. > > I removed it, because I did not clearly understand it (maybe my English > is not good enough). Do you means each one IS a key, or they altogether > ARE THE flow key? > > If you consider 'flow key' to be an important term, than I suggest > giving it its own entry in the terminology section. > > Each field is termed key or flow key . Yes we can add it as a term > in the terminology. Fine. > > >>> >>> This definition covers the range from a flow containing all >>> packets observed at a network interface to a flow consisting of >>> just a single packet between two applications with a specific >>> sequence number. >> >> The range could be broader. A flow could contain all packets >> observed at one or more network interfaces. > > Right! It may even be an aggregate of packets selected at different > probes in the network. > > Let's change this phrase to "... range from a flow containing all > packets observed at different probes distributed in a network to ..." > > Just out of curiosity are there deploymens that use flows in such > a manner for probes? I am not dealing with commercial deployments, but I remember that about three years ago I was involved in a customer trial where we used NetFlowMet to aggregate flows measured at several Cisco routers and then exported these flows using the Meter MIB. >>> Please note that the flow definition does not >>> match a general application-level end-to-end stream. >> >> I am not sure I understand this? A flow "could" match a general >> application-level end-to-end stream. But it is not restricted >> to this only. Is there a need to mention these lines or do you think >> the flow defintion is not clear enough? > > Well, initially I considered it to be clear enough without this > statement. But then I learned that too many people (on the list > and in private discussions) ignored this fact even after reading > it. I guess the reason is that the term 'flow' is already around > for some time, and if you are used to think about a flow as an > application level flow it can be hard to work with a different > definition. > So, the idea behind the redundant 'reminder' is reduce the number > of people mixing up the definitions. > > Can we re-phrase the paragragh then to: > Though a flow could match a general application-level end-to-end > stream, it's defintion not restricted to this alone. Yes, fine. > > >>> However, >>> an application may derive properties of application-level >>> streams by processing measured flow data. >>> >>> * Observation Point >>> The observation point is a location in the network where IP >>> packets can be observed. Examples are a line to which a probe >>> is attached, a shared medium, such as an Ethernet-based LAN, >>> a single port of a router, or the routing engine of a router. >> >> Why is "a set of interfaces (physical or logical) of a router" from the >> arch. spec omitted? Aggregation of ports (like fast ether channels in >> Cisco routers) is used very much in deployments. > > Isn't this rather an observation domain? > > No. Atleast on a router (I'm not sure about probes) we can group a > set of ports , say 5 fast ethernet ports to form a "port channel" . This > interface from a L3 perspective for any traffic coming on these > 5 fast ethernets is the "port channel". Similarly a tunnel interface (GRE) > can span over multiple physical interfaces. OK, then let's add it again. > > >>> >>> >>> * Observation Domain >>> A single IP traffic flow may contain packets observed at several >>> different observation points, for example at several ports of a >>> line card or at different probes. The observation domain of a >>> flow is the set of observation points at which the packets of >>> this flow have been or might have been observed. The minimal >>> observation domain contains just a single observation point. >> >> From the definition above , it would mean if R1 and R2 collect >> {Src AS, dst AS} on their respective n/w interfaces I1 and I2, then >> {I1, I2} would make up an observation domain!! Let me >> try to explain what I had in mind on this defintion: >> The flows collected from various observation points could be subjected >> to a series of sampling and classification operation in some sequence. >> This result could be combining flows collected at different observation >> points. An example for this is: The raw flow (5-tuple) collected at >> 2 observation points O1 and O2, when a furthur classification is done >> to choose all the packets that match a certain destination address >> would result in aggregation within the node (by node I mean a router >> or a linecard which can be clearly identified as a network entity and >> capable of doing such aggregation). > > You can aggregate flows beyond boundaries of a single device, > for eample by aggregating flows measured by several probes at > a concentrator (see figure from my other posting below). > > +---+ +---+ +---+ > | E-+-> | E-+-> | E-+------------->---+ > | | | | | | | | | +---+ +-+-----+ > +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> > | | | | | | | | | | +---+ +-+-----+ > +-+-+ +-+-+ | O | | M | | E-+->---+ > | | | | +---+ | | | | | | > | M | +-+-+ | O | | M | > | | | | | | +---+ | | | +-----+ > | O | | O | | O | ->-+-C-E-+-> > +---+ +---+ +---+ +-----+ > > Protocol Remote Concentrator Proxy > Converter Observation > > What is the input to concentrator? Is it IPFIX flow records or packets itself? > For Protocol converter, remote observation, OD = O - M - MFR - SCE fits > in well. For the concetrator case I am not sure what C-M-E do. If you can explain > furthur then we can find out. Same is the case with proxy - what is the input to it? Input to both, the proxy and the concentrator are flow records. The proxy just forwards them. The concentrator adds another step of metering, aggregation and flow record maintenance and then exports potentially different flow records. So the concentrator model would be C - M - MFR - SCE - E. In this case the observation domain would include all Os, Ms, MFRs, and SCEs on the probes as well as M - MFR - SCE on the concentrator. Cheers, Juergen > > Thanks > Ganesh > > [...] -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Apr 3 09:34:57 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04326 for ; Wed, 3 Apr 2002 09:34:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16slRs-00074u-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Apr 2002 08:09:16 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16slRr-00074A-00 for ipfix-arch@net.doit.wisc.edu; Wed, 03 Apr 2002 08:09:15 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g33E8i869816; Wed, 3 Apr 2002 16:08:44 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA23601; Wed, 3 Apr 2002 16:08:31 +0200 Date: Wed, 03 Apr 2002 16:11:43 +0200 From: Juergen Quittek To: Ganesh Sadasivan , Benoit Claise cc: knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology Message-ID: <22686892.1017850303@[192.168.102.164]> In-Reply-To: <3CAA9EFA.B4EDC24E@cisco.com> References: <3CAA9EFA.B4EDC24E@cisco.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh, --On 02 April 2002 22:19 -0800 Ganesh Sadasivan wrote: > Benoit, > I guess there was a confusion about the term > "observation domain". Jurgene thought it was > meant to convey a collection of observation > points. > Ganesh Well, maybe I'm the only one. But now I've found a nice way of understanding your definiton well: I interpret the term 'observation domain' as the physical 'domain' in the router hardware where observation point, metering, and flow record maintaining functions are located :-) Cheers, Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Apr 3 11:36:51 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08498 for ; Wed, 3 Apr 2002 11:36:46 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16snRa-00020k-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Apr 2002 10:17:06 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16snRX-0001zy-00 for ipfix-arch@net.doit.wisc.edu; Wed, 03 Apr 2002 10:17:03 -0600 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-163.cisco.com [144.254.7.163]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA07804; Wed, 3 Apr 2002 18:16:16 +0200 (MET DST) Message-ID: <3CAB2AD0.3090203@cisco.com> Date: Wed, 03 Apr 2002 18:16:16 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: <3CA9C429.8000809@cisco.com> <19842932.1017847459@[192.168.102.164]> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen,
Hi Benoit,

I already explained to Ganesh that I misunderstood your definition
of observation domain, mainly because I did consider a domain
a topological entity, not a functional one and therefore just
interpreted it as a set of observation points without the metering
function and others inside. Now I understand your definiton.

My idea ws re-using your defintion, not overwriting it.
What I wanted to cover is the situation that a metering process
may merge packets observed at several different observation points
into one flow. Then it doea not make sense to define a flow as
a set of packets observed at a single observation point, but
potentially also as a set of observation points, which I
unfortunately called observation domain. Let's call it Set Of
Oberservation Points (SOOP) for the rest of this message. As far
as I understand, the SOOP is part of an observation domain.

Consequently, my proposal is to define a flow to be a set of
packets observed at a SOOP, not just at a single observation point.
Of course a SOOP may contain a single observation point only.
It was already the case before with the previous definitions without having a new term

2.1. IP Traffic Flows
   A flow is defined as a set of packets passing an observation point in
   the network during a certain time interval.

2.2. Observation Point

   The observation point is a location in the network where IP packets
   can be observed. Examples are a line to which a probe is attached, a
   shared medium, such as an Ethernet-based LAN, a single port of a
   router, or a set of interfaces (physical or logical) of a router .

Regards, Benoit


   Juergen

--On 02 April 2002 16:46 +0200 Benoit Claise <bclaise@cisco.com> wrote:

Hi Juergen,

Some comments.
Note that some of them were already made by Ganesh.

Hi KC,

Here is a revised version of the terminology for the
architecture document (as promised in Minneapolis).
Most of the changes result from discussions with Tanja.

The definitions of IPFIX device, template, control
stream and data stream are unchanged, although I am
not yet completely satisfied with them.
Further discussion on all terms seems to be ahead.

Cheers,

   Juergen


    Terminology

    * IP Traffic Flows
      A flow is defined as a set of packets passing an observation
      domain in the network during a certain time interval. All packets
      belonging to a particular flow have a set of common properties.
      Each property is defined as the result of applying a function to
      the values of:

You changed from passing an obervation point to an observation domain.
I prefered observation point; it was more self-explaining.
You define below the observation domain. But this term is already used in the architecture document for another purpose.
     * Observation Domain:
       The set of observation points which is the largest aggregatable
       set of flow information at the IPFIX Device is termed as an
       observation domain. The observation domain presents itself a
       unique ID to the collector for identifying the export packets
       generated by it. One or more Observation Domains can interface
       with the same export process. Example: The observation domain
       could be a router line-card, composed of several interfaces with
       each interface being an observation point.

This is confusing. That's the reason why I would put:
- move back to the definition containing "passing an observation point"
- remove the observation domain from the requirement.
- move back to the definition of the observation which contains "or a set of interfaces..." See my comments below

         1. one or more of packet header fields (eg. destination IP
            address)
         2. one or more properties of the packet itself (eg. packet length)
         3. one or more of fields derived from packet treatment (eg. AS
            number)

      A packet is defined to belong to a flow if it completely
      satisfies all the defined properties of the flow.

      This definition covers the range from a flow containing all
      packets observed at a network interface to a flow consisting of
      just a single packet between two applications with a specific
      sequence number. Please note that the flow definition does not
      match a general application-level end-to-end stream. However,
      an application may derive properties of application-level
      streams by processing measured flow data.

    * Observation Point
      The observation point is a location in the network where IP
      packets can be observed. Examples are a line to which a probe
      is attached, a shared medium, such as an Ethernet-based LAN,
      a single port of a router, or the routing engine of a router.

Continuing with the same optic as above. We don't need the observation domain, but we need to previous definition of the "observation point" which containted "... Examples are a line to which a probe is attached, a shared medium, such as an
Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router."


    * Observation Domain
      A single IP traffic flow may contain packets observed at several
      different observation points, for example at several ports of a
      line card or at different probes. The observation domain of a
      flow is the set of observation points at which the packets of
      this flow have been or might have been observed. The minimal
      observation domain contains just a single observation point.

    * Metering Process
      The metering process generates flow records. Input to the
      process are IP packets observed in an observation domain. The

should be: "observed at the observation point"

      metering process consists of a set of functions that includes
      packet header capturing, timestamping, sampling, classifying,
      and maintaining flow records.

      Sampling and classifying may be performed repeatedly (with
      different parameters). The sampling function selects a subset
      of the received set of items (packet headers with timestamps or
      flow records) to be passed further to the classifying function.
      The sampling function may be trivial by passing all items,
      which is equivalent to applying no sampling at all. The
      classifying function maps its input to flows. There are two
      extreme classifying functions: one mapping each packet to
      different flows and one mapping all packets to the same flow.

      Maintenance of flow records may include creating new records,
      updating existing ones, computing flow statistics, deriving further
      flow properties, detecting flow expiration, passing flows record to
      the exporting process, and deleting flow records.

      The figure below shows the sequence in which the functions are
    applied.

                           packet header capturing
                                     |
                                timestamping
                                     |
                                     v
                              +----->+
                              |      |
                              |   sampling
                              |      |
                              | classifying
                              |      |
                              +------+
                                     |
                          maintaining flow records
                                     |
                                     v

                 Figure 1: Functions of the metering process


    * Flow Record
      A flow record contains information about a specific flow that was
      metered in an observation domain. A flow record contains measured

Again, observation domain -> obvservation point.
This should be the same for all over.

Regards, Benoit

      properties of the flow (e.g. the total number of bytes of all packets
      of the flow) and usually characteristic properties of the flow (e.g.
      source IP address).

    * Exporting Process
      The exporting process sends flow records to one or more collectors.
      The flow records are generated by one or more metering processes.

    * Collecting Process
      The collecting process receives flow records from one or more
    exporting
      processes. The collecting process might store received flow record
      or further process them, but these actions are out of the scope of
      this document.

    * IPFIX Device:
      A device hosting at least an observation point, a metering
      process and a flow information export process. Typically,
      corresponding observation point(s), metering process(es), and
      exporter process(es) are co-located at this device, for example,
      at a router.

    * Template:
      Templates is a set of {type, length} ordered pairs, used to
      completely identify the structure and semantics of a particular
      information that needs to be communicated from the IPFIX Device
      to the collector. Each template is uniquely identified by a
      Template ID.

    * Control Stream, Data Stream:
      The information that needs to be exported from the IPFIX device
      can be classified into the following categories:

        - Control Information :
          This includes the flow type definition, selection criteria
          for packets within the flow. This is also called as Control
          Stream.
        - Flow record :
          This includes data records corresponding to the various
          observed flows at each of the observation point. This is also
          called as Data Stream.







-- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Apr 3 14:35:29 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13500 for ; Wed, 3 Apr 2002 14:35:29 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16spyd-0005cW-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Apr 2002 12:59:23 -0600 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16spyb-0005bo-00 for ipfix@net.doit.wisc.edu; Wed, 03 Apr 2002 12:59:21 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g33IwbV05639; Wed, 3 Apr 2002 10:58:38 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-17.cisco.com [171.71.137.17]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABT68263; Wed, 3 Apr 2002 10:59:21 -0800 (PST) Message-ID: <3CAB50E8.F3F4CA90@cisco.com> Date: Wed, 03 Apr 2002 10:58:49 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] data-model doc: uni-/bi-directional flows References: <20833967.1017848450@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jurgene, I agree with you. "A flow defined by the above terms MAY be unidirectional or bidirectional". But still we need a defintion for bi-directional flows as in section 4.2 - don't we? Thanks Ganesh Juergen Quittek wrote: > Hi all, > > I have a comment on section 4.2 of the data model document: > > 4.2. Unidirectional and Bidirectional Flows > > A flow defined by the above terms is unidirectional. In case the > exporter has got the knowledge of the bi-directional flows and in > case the bi-directional information make sense, the exporter MAY > choose to export in the same Template/Flow Record, along with > bidirectional accounting information. This would save some > bandwidth as the exporter won't have to send two unidirectional > flow records. > > I think the first sentence is wrong. I cannot see why our flow > defintion does imply a flow to be uni-directional. All examples > given in the data-model document are uni-directional flows, but > this does not say the defintion excludes bi-directional ones. > > Can anyone explain me, why our flows are uni-directional? > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Apr 3 17:40:20 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17895 for ; Wed, 3 Apr 2002 17:40:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16st4U-0000oJ-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Apr 2002 16:17:38 -0600 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16st4R-0000na-00 for ipfix-arch@net.doit.wisc.edu; Wed, 03 Apr 2002 16:17:35 -0600 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g33MGNMY018735; Wed, 3 Apr 2002 14:16:23 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-17.cisco.com [171.71.137.17]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABT76873; Wed, 3 Apr 2002 14:16:55 -0800 (PST) Message-ID: <3CAB7F36.45B79F59@cisco.com> Date: Wed, 03 Apr 2002 14:16:22 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: <3CAA9B02.B95DDA91@cisco.com> <22319443.1017849935@[192.168.102.164]> Content-Type: multipart/alternative; boundary="------------F1ECBD4278D5E372562E3F17" Precedence: bulk Sender: majordomo listserver --------------F1ECBD4278D5E372562E3F17 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jurgene, Juergen Quittek wrote: > > > > > +---+ +---+ +---+ > > | E-+-> | E-+-> | E-+------------->---+ > > | | | | | | | | | +---+ +-+-----+ > > +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> > > | | | | | | | | | | +---+ +-+-----+ > > +-+-+ +-+-+ | O | | M | | E-+->---+ (0) > > | | | | +---+ | | | | | | > > | M | +-+-+ (1) | O | | M | > > | | | | | | +---+ | | | +-----+ > > | O | | O | (2) | O | ->-+-C-E-+-> > > +---+ +---+ +---+ +-----+ > > (3) > > Protocol Remote Concentrator Proxy > > Converter Observation > > > > > Input to both, the proxy and the concentrator are flow records. > The proxy just forwards them. The concentrator adds another step > of metering, aggregation and flow record maintenance and then > exports potentially different flow records. So the concentrator > model would be C - M - MFR - SCE - E. In this case the observation > domain would include all Os, Ms, MFRs, and SCEs on the probes as > well as M - MFR - SCE on the concentrator. Ok. Let's take the concentrator case only. Can there not be multiple observation points and metering processes within (1), (2) and (3) ? Also if each of them export IPFIX flow records, then there are 3 observation domains O-M of (1), (2), (3). There could also be MFR and SCE optionally. Why can't the concentrator not be viewed as a collector with the additional M&E? Obviously I am missing something. An example would be great to understand this better. Thanks Ganesh --------------F1ECBD4278D5E372562E3F17 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jurgene,

Juergen Quittek wrote:

 
>
>        +---+     +---+     +---+
>        | E-+->   | E-+->   | E-+------------->---+
>        | | |     | | |     | | | +---+         +-+-----+
>        +-+-+     | M |     | M | | E-+------->-+-C-M-E-+->
>          |       | | |     | | | | | | +---+   +-+-----+
>        +-+-+     +-+-+     | O | | M | | E-+->---+ (0)
>        | | |       |       +---+ | | | | | |
>        | M |     +-+-+      (1)  | O | | M |
>        | | |     | | |           +---+ | | |           +-----+
>        | O |     | O |             (2) | O |        ->-+-C-E-+->
>        +---+     +---+                 +---+           +-----+
>                                         (3)
>       Protocol   Remote             Concentrator        Proxy
>       Converter  Observation
>
 

Input to both, the proxy and the concentrator are flow records.
The proxy just forwards them. The concentrator adds another step
of metering, aggregation and flow record maintenance and then
exports potentially different flow records. So the concentrator
model would be C - M - MFR - SCE - E. In this case the observation
domain would include all Os, Ms, MFRs, and SCEs on the probes as
well as M - MFR - SCE on the concentrator.


Ok. Let's take the concentrator case only. Can there not be multiple
observation points and metering processes within (1), (2) and (3) ?
Also if each of them export IPFIX flow records, then there are 3
observation domains O-M of  (1), (2), (3). There could also be
MFR and SCE optionally. Why can't the concentrator not be viewed
as a collector with the additional M&E? Obviously I am missing
something. An example would be great to understand this better.

Thanks
Ganesh
 
  --------------F1ECBD4278D5E372562E3F17-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Apr 3 18:20:22 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18544 for ; Wed, 3 Apr 2002 18:20:22 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16stmR-0001en-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Apr 2002 17:03:03 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16stmP-0001eI-00 for ipfix@net.doit.wisc.edu; Wed, 03 Apr 2002 17:03:01 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g33N2T886587; Thu, 4 Apr 2002 01:02:29 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA28411; Thu, 4 Apr 2002 01:02:14 +0200 Date: Thu, 04 Apr 2002 01:05:28 +0200 From: Juergen Quittek To: Ganesh Sadasivan cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] data-model doc: uni-/bi-directional flows Message-ID: <2257235.1017882327@[192.168.102.31]> In-Reply-To: <3CAB50E8.F3F4CA90@cisco.com> References: <3CAB50E8.F3F4CA90@cisco.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh, I agree. We should provide a definition of uni-directional and bi-directional flows. However, I would prefer to discuss these essential terms in the architecture document rather than in the document describing the information model of the IPFIX protocol. Juergen --On 03 April 2002 10:58 -0800 Ganesh Sadasivan wrote: > Jurgene, > I agree with you. "A flow defined by the above terms > MAY be unidirectional or bidirectional". > But still we need a defintion for bi-directional flows as > in section 4.2 - don't we? > Thanks > Ganesh > > Juergen Quittek wrote: > >> Hi all, >> >> I have a comment on section 4.2 of the data model document: >> >> 4.2. Unidirectional and Bidirectional Flows >> >> A flow defined by the above terms is unidirectional. In case the >> exporter has got the knowledge of the bi-directional flows and in >> case the bi-directional information make sense, the exporter MAY >> choose to export in the same Template/Flow Record, along with >> bidirectional accounting information. This would save some >> bandwidth as the exporter won't have to send two unidirectional >> flow records. >> >> I think the first sentence is wrong. I cannot see why our flow >> defintion does imply a flow to be uni-directional. All examples >> given in the data-model document are uni-directional flows, but >> this does not say the defintion excludes bi-directional ones. >> >> Can anyone explain me, why our flows are uni-directional? >> >> Juergen >> -- >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >> Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Apr 3 18:26:09 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18637 for ; Wed, 3 Apr 2002 18:26:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16stsb-0001lh-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Apr 2002 17:09:25 -0600 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16stsa-0001kz-00 for ipfix@net.doit.wisc.edu; Wed, 03 Apr 2002 17:09:24 -0600 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g33N8lMY014024; Wed, 3 Apr 2002 15:08:47 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-17.cisco.com [171.71.137.17]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABT79255; Wed, 3 Apr 2002 15:09:18 -0800 (PST) Message-ID: <3CAB8B7C.CB65D7F@cisco.com> Date: Wed, 03 Apr 2002 15:08:44 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] data-model doc: uni-/bi-directional flows References: <3CAB50E8.F3F4CA90@cisco.com> <2257235.1017882327@[192.168.102.31]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jurgene, No disagreements here. What we can do is to pull in all these into the terminology section of arch. spec. Ganesh Juergen Quittek wrote: > Ganesh, > > I agree. We should provide a definition of uni-directional > and bi-directional flows. > > However, I would prefer to discuss these essential terms > in the architecture document rather than in the document > describing the information model of the IPFIX protocol. > > Juergen > > --On 03 April 2002 10:58 -0800 Ganesh Sadasivan wrote: > > > Jurgene, > > I agree with you. "A flow defined by the above terms > > MAY be unidirectional or bidirectional". > > But still we need a defintion for bi-directional flows as > > in section 4.2 - don't we? > > Thanks > > Ganesh > > > > Juergen Quittek wrote: > > > >> Hi all, > >> > >> I have a comment on section 4.2 of the data model document: > >> > >> 4.2. Unidirectional and Bidirectional Flows > >> > >> A flow defined by the above terms is unidirectional. In case the > >> exporter has got the knowledge of the bi-directional flows and in > >> case the bi-directional information make sense, the exporter MAY > >> choose to export in the same Template/Flow Record, along with > >> bidirectional accounting information. This would save some > >> bandwidth as the exporter won't have to send two unidirectional > >> flow records. > >> > >> I think the first sentence is wrong. I cannot see why our flow > >> defintion does imply a flow to be uni-directional. All examples > >> given in the data-model document are uni-directional flows, but > >> this does not say the defintion excludes bi-directional ones. > >> > >> Can anyone explain me, why our flows are uni-directional? > >> > >> Juergen > >> -- > >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > >> Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > >> > >> -- > >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >> "unsubscribe ipfix" in message body > >> Archive http://ipfix.doit.wisc.edu/archive/ > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Apr 3 18:39:33 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19032 for ; Wed, 3 Apr 2002 18:39:32 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16su5h-00024L-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Apr 2002 17:22:57 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16su5e-00023m-00 for ipfix-arch@net.doit.wisc.edu; Wed, 03 Apr 2002 17:22:54 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g33NMN886780; Thu, 4 Apr 2002 01:22:23 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA28554; Thu, 4 Apr 2002 01:22:08 +0200 Date: Thu, 04 Apr 2002 01:25:21 +0200 From: Juergen Quittek To: Ganesh Sadasivan cc: ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology Message-ID: <3450822.1017883521@[192.168.102.31]> In-Reply-To: <3CAB7F36.45B79F59@cisco.com> References: <3CAB7F36.45B79F59@cisco.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Ganesh, --On 03 April 2002 14:16 -0800 Ganesh Sadasivan wrote: > Hi Jurgene, > > Juergen Quittek wrote: > > >> >> +---+ +---+ +---+ >> | E-+-> | E-+-> | E-+------------->---+ >> | | | | | | | | | +---+ +-+-----+ >> +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> >> | | | | | | | | | | +---+ +-+-----+ >> +-+-+ +-+-+ | O | | M | | E-+->---+ (0) >> | | | | +---+ | | | | | | >> | M | +-+-+ (1) | O | | M | >> | | | | | | +---+ | | | +-----+ >> | O | | O | (2) | O | ->-+-C-E-+-> >> +---+ +---+ +---+ +-----+ >> (3) >> Protocol Remote Concentrator Proxy >> Converter Observation >> > > > Input to both, the proxy and the concentrator are flow records. > The proxy just forwards them. The concentrator adds another step > of metering, aggregation and flow record maintenance and then > exports potentially different flow records. So the concentrator > model would be C - M - MFR - SCE - E. In this case the observation > domain would include all Os, Ms, MFRs, and SCEs on the probes as > well as M - MFR - SCE on the concentrator. > > > > Ok. Let's take the concentrator case only. Can there not be multiple > observation points and metering processes within (1), (2) and (3) ? > Also if each of them export IPFIX flow records, then there are 3 > observation domains O-M of (1), (2), (3). There could also be > MFR and SCE optionally. Why can't the concentrator not be viewed > as a collector with the additional M&E? Obviously I am missing > something. An example would be great to understand this better. I think I can agree to all your statements. The point is that the metering process on the concentrator may aggregate individual flows from (1), (2) and (3) to a merged flow. When this merged flow is exported, it is necessary to report where it has been measured. Then its observation domain includes (1), (2) and (3). So the observation domain for this flow extends over more than one box. This is where I have problems. Maybe we should exclude such an aggregation of flows measured by different boxes? Higher level aggregation beyond device boundaries can still be done by applications? Cheers, Juergen > Thanks > Ganesh > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Apr 3 19:42:38 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20147 for ; Wed, 3 Apr 2002 19:42:38 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16suzO-0003EM-00 for ipfix-list@mil.doit.wisc.edu; Wed, 03 Apr 2002 18:20:30 -0600 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16suzL-0003DA-00 for ipfix-arch@net.doit.wisc.edu; Wed, 03 Apr 2002 18:20:27 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g340JuX11121; Wed, 3 Apr 2002 16:19:56 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-17.cisco.com [171.71.137.17]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABT82124; Wed, 3 Apr 2002 16:20:27 -0800 (PST) Message-ID: <3CAB9C2A.7226EF33@cisco.com> Date: Wed, 03 Apr 2002 16:19:54 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: <3CAB7F36.45B79F59@cisco.com> <3450822.1017883521@[192.168.102.31]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > Hi Ganesh, > > --On 03 April 2002 14:16 -0800 Ganesh Sadasivan wrote: > > > Hi Jurgene, > > > > Juergen Quittek wrote: > > > > > >> > >> +---+ +---+ +---+ > >> | E-+-> | E-+-> | E-+------------->---+ > >> | | | | | | | | | +---+ +-+-----+ > >> +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> > >> | | | | | | | | | | +---+ +-+-----+ > >> +-+-+ +-+-+ | O | | M | | E-+->---+ (0) > >> | | | | +---+ | | | | | | > >> | M | +-+-+ (1) | O | | M | > >> | | | | | | +---+ | | | +-----+ > >> | O | | O | (2) | O | ->-+-C-E-+-> > >> +---+ +---+ +---+ +-----+ > >> (3) > >> Protocol Remote Concentrator Proxy > >> Converter Observation > >> > > > > > > Input to both, the proxy and the concentrator are flow records. > > The proxy just forwards them. The concentrator adds another step > > of metering, aggregation and flow record maintenance and then > > exports potentially different flow records. So the concentrator > > model would be C - M - MFR - SCE - E. In this case the observation > > domain would include all Os, Ms, MFRs, and SCEs on the probes as > > well as M - MFR - SCE on the concentrator. > > > > > > > > Ok. Let's take the concentrator case only. Can there not be multiple > > observation points and metering processes within (1), (2) and (3) ? > > Also if each of them export IPFIX flow records, then there are 3 > > observation domains O-M of (1), (2), (3). There could also be > > MFR and SCE optionally. Why can't the concentrator not be viewed > > as a collector with the additional M&E? Obviously I am missing > > something. An example would be great to understand this better. > > I think I can agree to all your statements. The point is that > the metering process on the concentrator may aggregate individual > flows from (1), (2) and (3) to a merged flow. When this merged > flow is exported, it is necessary to report where it has been > measured. Then its observation domain includes (1), (2) and (3). > So the observation domain for this flow extends over more than > one box. How does the export process function in (1) (2) and (3) ? Is it not same as the export process defined by IPFIX protocol? To me it looks like another level of aggregation beyond the IPFIX device boundary. > > > This is where I have problems. Maybe we should exclude such an > aggregation of flows measured by different boxes? Higher level > aggregation beyond device boundaries can still be done by > applications? Yes higher level aggreagtion is beyond the device boundary can be done by applications outside the scope of IPFIX. Thanks Ganesh > > > Cheers, > > Juergen > > > Thanks > > Ganesh > > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Apr 4 03:02:10 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06524 for ; Thu, 4 Apr 2002 03:02:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16t1qZ-0004tS-00 for ipfix-list@mil.doit.wisc.edu; Thu, 04 Apr 2002 01:39:51 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16t1qX-0004sx-00 for ipfix-arch@net.doit.wisc.edu; Thu, 04 Apr 2002 01:39:49 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g347dJ894368; Thu, 4 Apr 2002 09:39:19 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA32370; Thu, 4 Apr 2002 09:39:03 +0200 Date: Thu, 04 Apr 2002 09:42:18 +0200 From: Juergen Quittek To: Ganesh Sadasivan cc: ipfix-arch@net.doit.wisc.edu Subject: observation point limits (was: Re: [ipfix-arch] revised terminology) Message-ID: <3095961.1017913338@[192.168.102.164]> In-Reply-To: <3CAB9C2A.7226EF33@cisco.com> References: <3CAB9C2A.7226EF33@cisco.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh, Yes, that's the point: What - or where - is the IPFIX boundary? Is the maximum level of aggregation a single device? What is the largest observation point? Or: What is the largest set of observation points out of which observed packets may be aggregated into a single flow? - single interface of a single device - set of interfaces of a single device - all interfaces of a device ----------------- cut? ------------------ - several devices - entire network Cheers, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 03 April 2002 16:19 -0800 Ganesh Sadasivan wrote: > > Juergen Quittek wrote: > >> Hi Ganesh, >> >> --On 03 April 2002 14:16 -0800 Ganesh Sadasivan wrote: >> >> > Hi Jurgene, >> > >> > Juergen Quittek wrote: >> > >> > >> >> >> >> +---+ +---+ +---+ >> >> | E-+-> | E-+-> | E-+------------->---+ >> >> | | | | | | | | | +---+ +-+-----+ >> >> +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> >> >> | | | | | | | | | | +---+ +-+-----+ >> >> +-+-+ +-+-+ | O | | M | | E-+->---+ (0) >> >> | | | | +---+ | | | | | | >> >> | M | +-+-+ (1) | O | | M | >> >> | | | | | | +---+ | | | +-----+ >> >> | O | | O | (2) | O | ->-+-C-E-+-> >> >> +---+ +---+ +---+ +-----+ >> >> (3) >> >> Protocol Remote Concentrator Proxy >> >> Converter Observation >> >> >> > >> > >> > Input to both, the proxy and the concentrator are flow records. >> > The proxy just forwards them. The concentrator adds another step >> > of metering, aggregation and flow record maintenance and then >> > exports potentially different flow records. So the concentrator >> > model would be C - M - MFR - SCE - E. In this case the observation >> > domain would include all Os, Ms, MFRs, and SCEs on the probes as >> > well as M - MFR - SCE on the concentrator. >> > >> > >> > >> > Ok. Let's take the concentrator case only. Can there not be multiple >> > observation points and metering processes within (1), (2) and (3) ? >> > Also if each of them export IPFIX flow records, then there are 3 >> > observation domains O-M of (1), (2), (3). There could also be >> > MFR and SCE optionally. Why can't the concentrator not be viewed >> > as a collector with the additional M&E? Obviously I am missing >> > something. An example would be great to understand this better. >> >> I think I can agree to all your statements. The point is that >> the metering process on the concentrator may aggregate individual >> flows from (1), (2) and (3) to a merged flow. When this merged >> flow is exported, it is necessary to report where it has been >> measured. Then its observation domain includes (1), (2) and (3). >> So the observation domain for this flow extends over more than >> one box. > > How does the export process function in (1) (2) and (3) ? Is it not same > as the export process defined by IPFIX protocol? To me it looks like > another level of aggregation beyond the IPFIX device boundary. > [...] -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Apr 4 11:43:07 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22054 for ; Thu, 4 Apr 2002 11:43:07 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16t9vp-0001O1-00 for ipfix-list@mil.doit.wisc.edu; Thu, 04 Apr 2002 10:17:49 -0600 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16t9vm-0001Nr-00 for ipfix@net.doit.wisc.edu; Thu, 04 Apr 2002 10:17:46 -0600 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g34GKCH08399 for ; Thu, 4 Apr 2002 10:20:12 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 4 Apr 2002 10:17:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 10:17:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [ipfix] ipfix vs. RMON Date: Thu, 4 Apr 2002 11:17:11 -0500 Message-ID: Thread-Topic: ipfix vs. RMON Thread-Index: AcHb85L8Mk2pHtoOQfOkrbKpb1bSSg== From: To: X-OriginalArrivalTime: 04 Apr 2002 16:17:12.0663 (UTC) FILETIME=[2D999E70:01C1DBF4] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA22054 Hi, I was asked about what the differences between IPFIX and RMON (also defined at IETF) are. In particular, what IPFIX can do that RMON cannot do? My two cents are that IPFIX runs on top of reliable TCP, hence allows exporting large chunk of data. Whereas RMON runs on top of UDP, not efficient for large amount of data transporting. I may have missed the main points. So any comments are appreciated. Best regards Man Li -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Apr 4 12:02:28 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22973 for ; Thu, 4 Apr 2002 12:02:28 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16tAMN-00026I-00 for ipfix-list@mil.doit.wisc.edu; Thu, 04 Apr 2002 10:45:15 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16tAML-00026B-00 for ipfix@net.doit.wisc.edu; Thu, 04 Apr 2002 10:45:13 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id LAA20994; Thu, 4 Apr 2002 11:55:11 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma020961; Thu, 4 Apr 02 11:54:40 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <2GYJY87M>; Thu, 4 Apr 2002 11:42:44 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA086D@slc-exc1.ctron.com> From: "Norseth, KC" To: "'Man.M.Li@nokia.com'" , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] ipfix vs. RMON Date: Thu, 4 Apr 2002 11:43:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DBF7.EA0907F0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DBF7.EA0907F0 Content-Type: text/plain Hi, RMON and IPFIX are 2 different things. A lot of devices will have both enabled at the same time, where they are providing different information. Some of the differences: RMON - PULL data from collector IPFIX - PUSH data to collectors. RMON - Device statistics and alarms IPFIX - Flow information (IP Flow Information Export) RMON - Health of the device IPFIX - health of the network RMON - L2 & L3 IPFIX - L3 Hope this helps, there is a lot more than this, but this is a start. K.C. |-----Original Message----- |From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] |Sent: Thursday, April 04, 2002 9:17 AM |To: ipfix@net.doit.wisc.edu |Subject: [ipfix] ipfix vs. RMON | | |Hi, | |I was asked about what the differences between IPFIX and RMON |(also defined at IETF) are. In particular, what IPFIX can do |that RMON cannot do? | |My two cents are that IPFIX runs on top of reliable TCP, hence |allows exporting large chunk of data. Whereas RMON runs on top |of UDP, not efficient for large amount of data transporting. I |may have missed the main points. So any comments are appreciated. | |Best regards |Man Li | | |-- |Help mailto:majordomo@net.doit.wisc.edu and say "help" |in message body |Unsubscribe mailto:majordomo@net.doit.wisc.edu and say |"unsubscribe ipfix" in message body |Archive http://ipfix.doit.wisc.edu/archive/ | ------_=_NextPart_001_01C1DBF7.EA0907F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipfix] ipfix vs. RMON

Hi,

RMON and IPFIX are 2 different things.  A lot of = devices will have both enabled at the same time, where they are = providing different information.

Some of the differences:
RMON - PULL data from collector
IPFIX - PUSH data to collectors.

RMON - Device statistics and alarms
IPFIX - Flow information (IP Flow Information = Export)

RMON - Health of the device
IPFIX - health of the network

RMON - L2 & L3
IPFIX - L3

Hope this helps, there is a lot more than this, but = this is a start.

K.C.

|-----Original Message-----
|From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] =
|Sent: Thursday, April 04, 2002 9:17 AM
|To: ipfix@net.doit.wisc.edu
|Subject: [ipfix] ipfix vs. RMON
|
|
|Hi,
|
|I was asked about what the differences between = IPFIX and RMON
|(also defined at IETF) are. In particular, what = IPFIX can do
|that RMON cannot do?
|
|My two cents are that IPFIX runs on top of reliable = TCP, hence
|allows exporting large chunk of data. Whereas RMON = runs on top
|of UDP, not efficient for large amount of data = transporting. I
|may have missed the main points. So any comments = are appreciated.
|
|Best regards
|Man Li
|
|
|--
|Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
|in message body
|Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|"unsubscribe ipfix" in message = body
|Archive     http://ipfix.doit.wisc.edu/archive/
|

------_=_NextPart_001_01C1DBF7.EA0907F0-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Apr 4 12:15:35 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23816 for ; Thu, 4 Apr 2002 12:15:35 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16tAcT-0002ZC-00 for ipfix-list@mil.doit.wisc.edu; Thu, 04 Apr 2002 11:01:53 -0600 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16tAcR-0002YO-00; Thu, 04 Apr 2002 11:01:51 -0600 Received: from ccook.quarrytech.com (CCOOK [10.1.3.76]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2HGWJJQN; Thu, 4 Apr 2002 12:01:20 -0500 Message-Id: <4.3.1.0.20020404115915.02d52018@email.quarrytech.com> X-Sender: ccook@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 04 Apr 2002 12:07:07 -0500 To: , From: "Christopher R. Cook" Subject: Re: [ipfix] ipfix vs. RMON Cc: ipfix@net.doit.wisc.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk Sender: majordomo listserver RMON / RMON2 and SNMP in general were never designed to handle the incredible data volumes that will need to be transferred. IPFIX rides on to of TCP, more reliable however less efficient that UDP, but reliability is the key. The efficiencies (I hope) are being build in to IPFIX implementation... as both ( reliability & efficiency ) are required... Thoughts ? Cheers.. . At 11:17 AM 4/4/2002 -0500, Man.M.Li@nokia.com wrote: >Hi, > >I was asked about what the differences between IPFIX and RMON (also >defined at IETF) are. In particular, what IPFIX can do that RMON cannot do? > >My two cents are that IPFIX runs on top of reliable TCP, hence allows >exporting large chunk of data. Whereas RMON runs on top of UDP, not >efficient for large amount of data transporting. I may have missed the >main points. So any comments are appreciated. > >Best regards >Man Li > > >-- >Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >"unsubscribe ipfix" in message body >Archive http://ipfix.doit.wisc.edu/archive/ Christopher R. Cook Director of Product Management Voice (781) 359-5055 Quarry Technologies 8 New England Executive Park Burlington MA, 01803 -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Apr 4 12:54:58 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28270 for ; Thu, 4 Apr 2002 12:54:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16tB8N-0003MJ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 04 Apr 2002 11:34:51 -0600 Received: from c001-h005.c001.snv.cp.net ([209.228.32.119] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16tB8L-0003LX-00 for ipfix@net.doit.wisc.edu; Thu, 04 Apr 2002 11:34:49 -0600 Received: (cpmta 22870 invoked from network); 4 Apr 2002 09:34:18 -0800 Received: from 209.228.32.128 (HELO mail.norseth.com.criticalpath.net) by smtp.register-admin.com (209.228.32.119) with SMTP; 4 Apr 2002 09:34:18 -0800 X-Sent: 4 Apr 2002 17:34:18 GMT Received: from [12.25.1.128] by mail.norseth.com with HTTP; Thu, 04 Apr 2002 09:34:15 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 To: ccook@quarrytech.com Cc: Man.M.Li@nokia.com, ipfix@net.doit.wisc.edu, ipfix@net.doit.wisc.edu From: kcn@norseth.com Subject: Re: [ipfix] ipfix vs. RMON X-Sent-From: kcn@norseth.com Date: Thu, 04 Apr 2002 09:34:15 -0800 (PST) X-Mailer: Web Mail 5.0.8-8 Message-Id: <20020404093418.19160.c001-h014.c001.wm@mail.norseth.com.criticalpath.net> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit On Thu, 04 April 2002, "Christopher R. Cook" wrote > > RMON / RMON2 and SNMP in general were never designed to handle the > incredible data volumes that will need to be transferred. IPFIX rides on to > of TCP, more reliable however less efficient that UDP, but reliability is > the key. The efficiencies (I hope) are being build in to IPFIX > implementation... as both ( reliability & efficiency ) are required... TCP is not 100 percent, SCTP is a contendor for transmission protocol. The transmission protocol needs to be congestion aware. IPFIX is to select from existing protocols. So far, in each of the 3 main contenders, they have their own way for efffecient transfer. It will also be important to see how they handle overloading (network, exporting device, collector). K.C. > Thoughts ? > > Cheers.. > . > At 11:17 AM 4/4/2002 -0500, Man.M.Li@nokia.com wrote: > >Hi, > > > >I was asked about what the differences between IPFIX and RMON (also > >defined at IETF) are. In particular, what IPFIX can do that RMON cannot do? > > > >My two cents are that IPFIX runs on top of reliable TCP, hence allows > >exporting large chunk of data. Whereas RMON runs on top of UDP, not > >efficient for large amount of data transporting. I may have missed the > >main points. So any comments are appreciated. > > > >Best regards > >Man Li > > > > > Christopher R. Cook > Director of Product Management Voice (781) 359-5055 > Quarry Technologies > 8 New England Executive Park > Burlington MA, 01803 > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Apr 4 12:58:47 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28442 for ; Thu, 4 Apr 2002 12:58:46 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16tB8Q-0003MN-00 for ipfix-list@mil.doit.wisc.edu; Thu, 04 Apr 2002 11:34:54 -0600 Received: from c001-h005.c001.snv.cp.net ([209.228.32.119] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16tB8L-0003LY-00 for ipfix@net.doit.wisc.edu; Thu, 04 Apr 2002 11:34:49 -0600 Received: (cpmta 22870 invoked from network); 4 Apr 2002 09:34:18 -0800 Received: from 209.228.32.128 (HELO mail.norseth.com.criticalpath.net) by smtp.register-admin.com (209.228.32.119) with SMTP; 4 Apr 2002 09:34:18 -0800 X-Sent: 4 Apr 2002 17:34:18 GMT Received: from [12.25.1.128] by mail.norseth.com with HTTP; Thu, 04 Apr 2002 09:34:15 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 To: ccook@quarrytech.com Cc: Man.M.Li@nokia.com, ipfix@net.doit.wisc.edu, ipfix@net.doit.wisc.edu From: kcn@norseth.com Subject: Re: [ipfix] ipfix vs. RMON X-Sent-From: kcn@norseth.com Date: Thu, 04 Apr 2002 09:34:15 -0800 (PST) X-Mailer: Web Mail 5.0.8-8 Message-Id: <20020404093418.19160.c001-h014.c001.wm@mail.norseth.com.criticalpath.net> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit On Thu, 04 April 2002, "Christopher R. Cook" wrote > > RMON / RMON2 and SNMP in general were never designed to handle the > incredible data volumes that will need to be transferred. IPFIX rides on to > of TCP, more reliable however less efficient that UDP, but reliability is > the key. The efficiencies (I hope) are being build in to IPFIX > implementation... as both ( reliability & efficiency ) are required... TCP is not 100 percent, SCTP is a contendor for transmission protocol. The transmission protocol needs to be congestion aware. IPFIX is to select from existing protocols. So far, in each of the 3 main contenders, they have their own way for efffecient transfer. It will also be important to see how they handle overloading (network, exporting device, collector). K.C. > Thoughts ? > > Cheers.. > . > At 11:17 AM 4/4/2002 -0500, Man.M.Li@nokia.com wrote: > >Hi, > > > >I was asked about what the differences between IPFIX and RMON (also > >defined at IETF) are. In particular, what IPFIX can do that RMON cannot do? > > > >My two cents are that IPFIX runs on top of reliable TCP, hence allows > >exporting large chunk of data. Whereas RMON runs on top of UDP, not > >efficient for large amount of data transporting. I may have missed the > >main points. So any comments are appreciated. > > > >Best regards > >Man Li > > > > > Christopher R. Cook > Director of Product Management Voice (781) 359-5055 > Quarry Technologies > 8 New England Executive Park > Burlington MA, 01803 > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Apr 4 13:36:48 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03417 for ; Thu, 4 Apr 2002 13:36:47 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16tBph-0004SM-00 for ipfix-list@mil.doit.wisc.edu; Thu, 04 Apr 2002 12:19:37 -0600 Received: from mailhub.xacct.com ([204.253.100.25]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16tBpe-0004Rt-00 for ipfix@net.doit.wisc.edu; Thu, 04 Apr 2002 12:19:34 -0600 Received: (qmail 10145 invoked from network); 4 Apr 2002 18:18:57 -0000 Received: from unknown (HELO usmail.xacct.com) (204.253.100.12) by mailhub.us.xacct.com with SMTP; 4 Apr 2002 18:18:56 -0000 Received: from peter ([192.168.254.123]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g34IJ7M01165 for ; Thu, 4 Apr 2002 10:19:07 -0800 From: "Peter Ludemann" To: Subject: RE: [ipfix] ipfix vs. RMON Date: Thu, 4 Apr 2002 10:19:01 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.3.1.0.20020404115915.02d52018@email.quarrytech.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Does anybody have any figures to back up the statement that "TCP is less efficient than UDP" when working on a LAN, with no packet loss, duplication, or reordering? [Or even working over a WAN; because a UDP-based system would also need to do retransmission and congestion handling.] NFS-3 seems to indicate that there is no significant loss in efficiency. If there is a significant efficiency issue, we should note it. If there is no significant efficiency issue, we should put the matter to rest. [I did look at Ganesh's presentation http://ipfix.doit.wisc.edu/IETF52/1_ipfix-export-using-tcp.ppt; but it wasn't clear to me how much was due to the particular way that TCP was implemented on his system - there seemed to be more copies than needed, for example and I didn't see a comparison with UDP, and it wasn't clear to me whether this was a theoretical calculation or actual measurements.] There might be inefficiencies in particular TCP stacks, although that can be minimised by techniques such as scatter/gather write (an option in the Berkeley socket library). [I don't have any figures beyond what I found posted http://ipfix.doit.wisc.edu/archive/0823.html; but I can tell you that at 1000 rec/sec (25 fields, about 100 bytes total), I can barely measure the CPU (user/system/kernel) on a Solaris system (in burst tests, without any special tuning, we've done much faster - and this is without attempting to minimise data copying (either in queuing up the records or in calling the send() routine ... we have an implementation that avoids data copy but we're not currently using it in our test systems because its API is more complex and there doesn't seem to be a need for our current applications). I'd like to have more precise numbers, but that would require a more sophisticated measurement system, possibly using a real-time system, and unfortunately I don't have time to investigate further at the moment.] Peter Ludemann +1.408.330.5732 Chief Architect +1.650.248.3973 (mobile) XACCT Technologies peter.ludemann@xacct.com 2900 Lakeside Drive http://www.xacct.com Santa Clara CA 95054 > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Christopher R. Cook > Sent: Thursday, April 04, 2002 9:07 AM > To: Man.M.Li@nokia.com; ipfix@net.doit.wisc.edu > Cc: ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] ipfix vs. RMON > > > RMON / RMON2 and SNMP in general were never designed to handle the > incredible data volumes that will need to be transferred. IPFIX > rides on to > of TCP, more reliable however less efficient that UDP, but reliability is > the key. The efficiencies (I hope) are being build in to IPFIX > implementation... as both ( reliability & efficiency ) are required... > > Thoughts ? > > Cheers.. > . > At 11:17 AM 4/4/2002 -0500, Man.M.Li@nokia.com wrote: > >Hi, > > > >I was asked about what the differences between IPFIX and RMON (also > >defined at IETF) are. In particular, what IPFIX can do that RMON > cannot do? > > > >My two cents are that IPFIX runs on top of reliable TCP, hence allows > >exporting large chunk of data. Whereas RMON runs on top of UDP, not > >efficient for large amount of data transporting. I may have missed the > >main points. So any comments are appreciated. > > > >Best regards > >Man Li > > > > > >-- > >Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >"unsubscribe ipfix" in message body > >Archive http://ipfix.doit.wisc.edu/archive/ > > Christopher R. Cook > Director of Product Management Voice (781) 359-5055 > Quarry Technologies > 8 New England Executive Park > Burlington MA, 01803 > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 5 09:57:00 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06413 for ; Fri, 5 Apr 2002 09:56:59 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16tUo9-0000wI-00 for ipfix-list@mil.doit.wisc.edu; Fri, 05 Apr 2002 08:35:17 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16tUo7-0000v9-00 for ipfix-arch@net.doit.wisc.edu; Fri, 05 Apr 2002 08:35:15 -0600 Received: from riverstonenet.com (134.141.180.94 [134.141.180.94]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H23R67LH; Fri, 5 Apr 2002 06:33:42 -0800 Message-ID: <3CADB5C6.C8E36C3F@riverstonenet.com> Date: Fri, 05 Apr 2002 09:33:42 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan CC: Juergen Quittek , knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: <12205450.1017371280@[192.168.102.31]> <3CA8A88F.A6D27750@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh Sadasivan wrote: > > Hi Jurgene, Tanja, > > Juergen Quittek wrote: > > > Hi KC, > > > > Here is a revised version of the terminology for the > > architecture document (as promised in Minneapolis). > > Most of the changes result from discussions with Tanja. > > > > The definitions of IPFIX device, template, control > > stream and data stream are unchanged, although I am > > not yet completely satisfied with them. > > Further discussion on all terms seems to be ahead. > > > > Cheers, > > > > Juergen > > -- > > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > > Terminology > > > > * IP Traffic Flows > > A flow is defined as a set of packets passing an observation > > domain in the network during a certain time interval. All packets > > belonging to a particular flow have a set of common properties. > > Each property is defined as the result of applying a function to > > the values of: > > > > 1. one or more of packet header fields (eg. destination IP > > address) > > 2. one or more properties of the packet itself (eg. packet length) > > 3. one or more of fields derived from packet treatment (eg. AS > > number) > > > > A packet is defined to belong to a flow if it completely > > satisfies all the defined properties of the flow. > > The sentence "Each of the fields from 1., 2. and 3. are referred to > as keys. " (from the arch spec) seems to be omitted here. This is > required for introducing the definition of flow type. What I feel is > appropriate is to pick up the entire defintion including examples > from the data model doc and stick it here also. I think he outlines a general model which is what you want in a req. The other doucments can get into greater detail and definiyion. My 2 cents. > > > > > > > This definition covers the range from a flow containing all > > packets observed at a network interface to a flow consisting of > > just a single packet between two applications with a specific > > sequence number. > > The range could be broader. A flow could contain all packets > observed at one or more network interfaces. > > > Please note that the flow definition does not > > match a general application-level end-to-end stream. > > I am not sure I understand this? A flow "could" match a general > application-level end-to-end stream. But it is not restricted > to this only. Is there a need to mention these lines or do you think > the flow defintion is not clear enough? Most people think of a flow as an application level flow. I think it is good to point out here that we have a more general definition. > > > However, > > an application may derive properties of application-level > > streams by processing measured flow data. > > > > * Observation Point > > The observation point is a location in the network where IP > > packets can be observed. Examples are a line to which a probe > > is attached, a shared medium, such as an Ethernet-based LAN, > > a single port of a router, or the routing engine of a router. > > Why is "a set of interfaces (physical or logical) of a router" from the > arch. spec omitted? Aggregation of ports (like fast ether channels in > Cisco routers) is used very much in deployments. > > > > > > > * Observation Domain > > A single IP traffic flow may contain packets observed at several > > different observation points, for example at several ports of a > > line card or at different probes. The observation domain of a > > flow is the set of observation points at which the packets of > > this flow have been or might have been observed. The minimal > > observation domain contains just a single observation point. > > From the definition above , it would mean if R1 and R2 collect > {Src AS, dst AS} on their respective n/w interfaces I1 and I2, then > {I1, I2} would make up an observation domain!! Let me > try to explain what I had in mind on this defintion: > The flows collected from various observation points could be subjected > to a series of sampling and classification operation in some sequence. > This result could be combining flows collected at different observation > points. An example for this is: The raw flow (5-tuple) collected at > 2 observation points O1 and O2, when a furthur classification is done > to choose all the packets that match a certain destination address > would result in aggregation within the node (by node I mean a router > or a linecard which can be clearly identified as a network entity and > capable of doing such aggregation). > Observation domain consists of the set of observation points, the > metering processes, the part of maintenance of flow records (which > includes functions like aggregation) and choosing a criteria for > export. I'm not sure I follow 100% but if we modified Observation point to look at packets and IPFIX flows. Then combining O1 and O2 would just then make another O3? Just an idea. > > > > > > > * Metering Process > > The metering process generates flow records. Input to the > > process are IP packets observed in an observation domain. The > > metering process consists of a set of functions that includes > > packet header capturing, timestamping, sampling, classifying, > > and maintaining flow records. > > > > Sampling and classifying may be performed repeatedly (with > > different parameters). The sampling function selects a subset > > of the received set of items (packet headers with timestamps or > > flow records) to be passed further to the classifying function. > > The sampling function may be trivial by passing all items, > > which is equivalent to applying no sampling at all. The > > classifying function maps its input to flows. There are two > > extreme classifying functions: one mapping each packet to > > different flows and one mapping all packets to the same flow. > > > > Maintenance of flow records may include creating new records, > > updating existing ones, computing flow statistics, deriving further > > flow properties, detecting flow expiration, passing flows record to > > the exporting process, and deleting flow records. > > Maintenance of flow record can be thought of as a function of > observation domain . One more functionality which is outside > the metering process is a selection criteria for export. > > > > > > > The figure below shows the sequence in which the functions are applied. > > > > packet header capturing > > | > > timestamping > > | > > v > > +----->+ > > | | > > | sampling > > | | > > | classifying > > | | > > +------+ > > | > > maintaining flow records > > | > > v > > > > Figure 1: Functions of the metering process > > > > * Flow Record > > A flow record contains information about a specific flow that was > > metered in an observation domain. A flow record contains measured > > properties of the flow (e.g. the total number of bytes of all packets > > of the flow) and usually characteristic properties of the flow (e.g. > > source IP address). > > > > * Exporting Process > > The exporting process sends flow records to one or more collectors. > > The flow records are generated by one or more metering processes. > > There could be an option export criteria at the observation domain which > chooses which records to export. > Ganesh > > > > > > > * Collecting Process > > The collecting process receives flow records from one or more exporting > > processes. The collecting process might store received flow record > > or further process them, but these actions are out of the scope of > > this document. > > > > * IPFIX Device: > > A device hosting at least an observation point, a metering > > process and a flow information export process. Typically, > > corresponding observation point(s), metering process(es), and > > exporter process(es) are co-located at this device, for example, > > at a router. > > > > * Template: > > Templates is a set of {type, length} ordered pairs, used to > > completely identify the structure and semantics of a particular > > information that needs to be communicated from the IPFIX Device > > to the collector. Each template is uniquely identified by a > > Template ID. > > > > * Control Stream, Data Stream: > > The information that needs to be exported from the IPFIX device > > can be classified into the following categories: > > > > - Control Information : > > This includes the flow type definition, selection criteria > > for packets within the flow. This is also called as Control > > Stream. > > - Flow record : > > This includes data records corresponding to the various > > observed flows at each of the observation point. This is also > > called as Data Stream. > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 5 09:57:06 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06425 for ; Fri, 5 Apr 2002 09:57:05 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16tUny-0000w2-00 for ipfix-list@mil.doit.wisc.edu; Fri, 05 Apr 2002 08:35:06 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16tUnw-0000uu-00 for ipfix-arch@net.doit.wisc.edu; Fri, 05 Apr 2002 08:35:04 -0600 Received: from riverstonenet.com (134.141.180.94 [134.141.180.94]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H23R67LD; Fri, 5 Apr 2002 06:33:31 -0800 Message-ID: <3CADB5BA.F3E7D73D@riverstonenet.com> Date: Fri, 05 Apr 2002 09:33:31 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: <12205450.1017371280@[192.168.102.31]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > > Hi KC, > > Here is a revised version of the terminology for the > architecture document (as promised in Minneapolis). > Most of the changes result from discussions with Tanja. > > The definitions of IPFIX device, template, control > stream and data stream are unchanged, although I am > not yet completely satisfied with them. > Further discussion on all terms seems to be ahead. > > Cheers, > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > Terminology > > * IP Traffic Flows > A flow is defined as a set of packets passing an observation > domain in the network during a certain time interval. All packets > belonging to a particular flow have a set of common properties. > Each property is defined as the result of applying a function to > the values of: > > 1. one or more of packet header fields (eg. destination IP > address) > 2. one or more properties of the packet itself (eg. packet length) > 3. one or more of fields derived from packet treatment (eg. AS > number) > > A packet is defined to belong to a flow if it completely > satisfies all the defined properties of the flow. > > This definition covers the range from a flow containing all > packets observed at a network interface to a flow consisting of > just a single packet between two applications with a specific > sequence number. Please note that the flow definition does not > match a general application-level end-to-end stream. However, > an application may derive properties of application-level > streams by processing measured flow data. > > * Observation Point > The observation point is a location in the network where IP > packets can be observed. Examples are a line to which a probe > is attached, a shared medium, such as an Ethernet-based LAN, > a single port of a router, or the routing engine of a router. > > * Observation Domain > A single IP traffic flow may contain packets observed at several > different observation points, for example at several ports of a > line card or at different probes. The observation domain of a > flow is the set of observation points at which the packets of > this flow have been or might have been observed. The minimal > observation domain contains just a single observation point. > > * Metering Process > The metering process generates flow records. Input to the > process are IP packets observed in an observation domain. The > metering process consists of a set of functions that includes > packet header capturing, timestamping, sampling, classifying, > and maintaining flow records. > > Sampling and classifying may be performed repeatedly (with > different parameters). The sampling function selects a subset > of the received set of items (packet headers with timestamps or > flow records) to be passed further to the classifying function. > The sampling function may be trivial by passing all items, > which is equivalent to applying no sampling at all. The > classifying function maps its input to flows. There are two > extreme classifying functions: one mapping each packet to > different flows and one mapping all packets to the same flow. > > Maintenance of flow records may include creating new records, > updating existing ones, computing flow statistics, deriving further > flow properties, detecting flow expiration, passing flows record to > the exporting process, and deleting flow records. > > The figure below shows the sequence in which the functions are applied. > > packet header capturing > | > timestamping > | > v > +----->+ > | | > | sampling > | | > | classifying > | | > +------+ > | > maintaining flow records > | > v > > Figure 1: Functions of the metering process > > * Flow Record > A flow record contains information about a specific flow that was > metered in an observation domain. A flow record contains measured > properties of the flow (e.g. the total number of bytes of all packets > of the flow) and usually characteristic properties of the flow (e.g. > source IP address). > > * Exporting Process > The exporting process sends flow records to one or more collectors. > The flow records are generated by one or more metering processes. > > * Collecting Process > The collecting process receives flow records from one or more exporting > processes. The collecting process might store received flow record > or further process them, but these actions are out of the scope of > this document. > > * IPFIX Device: > A device hosting at least an observation point, a metering > process and a flow information export process. Typically, > corresponding observation point(s), metering process(es), and > exporter process(es) are co-located at this device, for example, > at a router. > > * Template: > Templates is a set of {type, length} ordered pairs, used to > completely identify the structure and semantics of a particular > information that needs to be communicated from the IPFIX Device > to the collector. Each template is uniquely identified by a > Template ID. This talks solution not req. What if we decided to do it as a hardcoded record. > > * Control Stream, Data Stream: > The information that needs to be exported from the IPFIX device > can be classified into the following categories: > > - Control Information : > This includes the flow type definition, selection criteria > for packets within the flow. This is also called as Control > Stream. > - Flow record : > This includes data records corresponding to the various > observed flows at each of the observation point. This is also > called as Data Stream. > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 5 10:15:54 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07006 for ; Fri, 5 Apr 2002 10:15:54 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16tVDW-0001YD-00 for ipfix-list@mil.doit.wisc.edu; Fri, 05 Apr 2002 09:01:30 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16tVDT-0001Xa-00 for ipfix-arch@net.doit.wisc.edu; Fri, 05 Apr 2002 09:01:28 -0600 Received: from riverstonenet.com (134.141.180.94 [134.141.180.94]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H23R67R1; Fri, 5 Apr 2002 06:59:54 -0800 Message-ID: <3CADBBE9.BF89BD@riverstonenet.com> Date: Fri, 05 Apr 2002 09:59:53 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] Feedback on the architecture draft References: <3CAA0F59.4080503@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > > All, > > Some comments on the latest architecture version f: > http://ipfix.doit.wisc.edu/arch/draft-ietf-ipfix-architecture-00f.txt > Next to what has been decided in Minneapolis. > > 1. Terminology > -------------- > As we can see on the mailing list, the terminology is a big issue. I think there are too many places where we have a terminology section: the > requirement, the architecture and the data model. To make sure that we are all speaking about the same terminology in the architecture and in > the data model (based on the definitions from the requirement), in order to remove any references from the architecture to the data model and vice versa... in 2 words... to avoid confusion, I propose to: > - add this note before the termonilogy sections of the architecture > draft and the data model draft > "Note that this terminology section contains the same definitions as in > the terminology section of the [IPFIX-DATA] | [IPFIX-ARCHI]" > - make all definitions redundant in both drafts. It just costs a cut-and-paste but it's a lot clearer > - put the entire definition in both drafts. Ex: the IP traffic Flow should even contain the examples Seems reasonable. > > 2. Metering Process Functions > ----------------------------- > As I proposed in Minneapolis, the entire section 5 "Metering Process Functions" from the data model should be inserted under the section 4 "IPFIX reference model" from the architecture model: > 4.1 Metering Process Functions > 4.1.1 flow classification > 4.1.2 selection criteria of packets > 4.1.2.1 function on properties that determines a flow type (Fi) > 4.1.2.2 sampling packets on a flow type (Si) > 4.1.3 selection criteria of flows for export > 4.1.4 flow expiration There was also a proposal not to do that as well. Again, The architecture defines what to do with flows. The data model will define the details of a flow in terms of fields available, functions available, etc.. Only a loose definintion need be in the Arch. > > 3. IPFIX reference model > ------------------------ > The "optional metering process (flow level)" must be replaced by selection criteria of flow for export. Because this doesn't fit into the > metering process definition: " The metering process generates flow records. Input to the process are IP packets observed ..." > Then we need a new paragraph under the section 4, referencing the Si and Fi definition that we just added in the architecture draft (see point number 2). > 4.2 Selection Criteria of flows for export > The measurement device MAY define additional rules so that only > certain flows records are picked up for export. This MAY be done by > either one of the two types of methods defined in 4.1.2.1 and 4.1.2.2 or > a combination of them. > Example: > The flow records which meets the following selection criteria are > only exported. > 1. All flow records whose destination IP address matches > {20.3.1.5}. > 2. Every other (.i.e sampling rate 1 in 2) flow record whose > destination IP address matches {160.0.1.30}. > > 4. Collector > ------------ > In the section 4.4, we can read > "The functions of the collector MAY include: > * Identifying and accepting export packets from different (Export Process, Observation Domain) pairs" > This last sentence should be changed to: > "* Identifying, accepting and decoding export packets from different (Export Process, Observation Domain) pairs" > > Again in 4.4, the following chapter should be removed, as it's contained in 4.5 already > " The application(s) and the collector may be tightly coupled in one > system. They may also be logically or physically a separate > subsystem from the application(s). In which case, the communication > between them is beyond the scope of IPFIX. " > > 5. Table of Content > ------------------- > There is no chapter 5.4, while there is chapter 5.5 > > Plus some minor corrections (mostly typo's) that I forwarded directly to Ganesh. I won't bother the mailing list with details. > > Regards, Benoit > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 5 10:16:58 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07037 for ; Fri, 5 Apr 2002 10:16:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16tVEx-0001a8-00 for ipfix-list@mil.doit.wisc.edu; Fri, 05 Apr 2002 09:02:59 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16tVEu-0001ZL-00 for ipfix-arch@net.doit.wisc.edu; Fri, 05 Apr 2002 09:02:56 -0600 Received: from riverstonenet.com (134.141.180.94 [134.141.180.94]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H23R67SW; Fri, 5 Apr 2002 07:01:23 -0800 Message-ID: <3CADBC41.16851B63@riverstonenet.com> Date: Fri, 05 Apr 2002 10:01:21 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: kevin.zhang@xacct.com CC: Benoit Claise , Juergen Quittek , ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit "kevin.zhang" wrote: > > Hi Benoit, > > I would like to underscore the point that control information is bi-directional, especially now as TCP is selected as the transport protocol. Please let me know some specifics of my proposal that you don't like, I sure can revise my proposal. When did we select TCP? I thought the requirement was congestion aware. > > Thanks, > > Kevin > > > -----Original Message----- > > From: Benoit Claise [mailto:bclaise@cisco.com] > > Sent: Tuesday, April 02, 2002 10:36 AM > > To: kevin.zhang@xacct.com > > Cc: Juergen Quittek; ipfix-arch@net.doit.wisc.edu > > Subject: Re: [ipfix-arch] revised terminology > > > > > > All, > > > > kevin.zhang wrote: > > > > > > > >> * Control Stream, Data Stream: > > >> The information that needs to be exported from the IPFIX device > > >> can be classified into the following categories: > > >> > > >> - Control Information : > > >> This includes the flow type definition, selection criteria > > >> for packets within the flow. This is also called as Control > > >> Stream. > > >> > > I would just say: > > - Control Information : > > This includes the flow type definition, selection criteria > > for packets within the flow and any other control messages. > > > > Regards, Benoit > > > > >> > > >> - Flow record : > > >> This includes data records corresponding to the various > > >> observed flows at each of the observation point. This is also > > >> called as Data Stream. > > >> > > >Based on our discussions in Minneapolis, the term "Control > > Stream" was not agreed upon. It appeared people like to use > > something else like "control information", and it is exchanged > > between IPFIX end points. My proposal is - > > > > > >*Control Information, Data Stream: > > >The information that needs to be exchanged between IPFIX devices > > can be classified into the following categories: > > > > > >- Control Information: > > >Control information is exchanged between IPFIX devices to > > facilitate flow record exporting. It includes the flow type > > definition, selection criteria for packets within the flow, and > > device capabilities. > > > > > >- Flow record: > > >This includes data records corresponding to the various observed > > flows at each of the observation point. This is also called as > > Data Stream. > > > > > i??s?Sݢj'zhS"?ݱzZb?gn?rR{.n+?j)mfhs?޵"qnjwlk+r>z*_<?,j>?bmYS-"qn?+ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 5 10:52:02 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07986 for ; Fri, 5 Apr 2002 10:52:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16tVga-0002BY-00 for ipfix-list@mil.doit.wisc.edu; Fri, 05 Apr 2002 09:31:32 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16tVgY-0002Ao-00 for ipfix@net.doit.wisc.edu; Fri, 05 Apr 2002 09:31:30 -0600 Received: from riverstonenet.com (134.141.180.94 [134.141.180.94]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H23R68B2; Fri, 5 Apr 2002 07:29:58 -0800 Message-ID: <3CADC2F5.A9E08187@riverstonenet.com> Date: Fri, 05 Apr 2002 10:29:57 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Norseth, KC" , "'Man.M.Li@nokia.com'" CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] ipfix vs. RMON References: <59358A738F45D51186A30008C74CE250DA086D@slc-exc1.ctron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit RMON covers a lot more functionality than IPFIX. But I assume you are referring to the portion that overlaps with IPFIX. From a functional level, they are similar. The main differences are one of implementation. KC outline several of them already. I'd like to add another, RMON stores a lot more data on the device and requires a lot more memory. IPFIX's goal, I believe is to get the data off the box quickly for later analysis. Again, IPFIX is aiming at high volume data which RMON was not designed for. Paul "Norseth, KC" wrote: > > Hi, > > RMON and IPFIX are 2 different things. A lot of devices will have > both enabled at the same time, where they are providing different > information. > > Some of the differences: > RMON - PULL data from collector > IPFIX - PUSH data to collectors. > > RMON - Device statistics and alarms > IPFIX - Flow information (IP Flow Information Export) > > RMON - Health of the device > IPFIX - health of the network > > RMON - L2 & L3 > IPFIX - L3 > > Hope this helps, there is a lot more than this, but this is a start. > > K.C. > > |-----Original Message----- > |From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] > |Sent: Thursday, April 04, 2002 9:17 AM > |To: ipfix@net.doit.wisc.edu > |Subject: [ipfix] ipfix vs. RMON > | > | > |Hi, > | > |I was asked about what the differences between IPFIX and RMON > |(also defined at IETF) are. In particular, what IPFIX can do > |that RMON cannot do? > | > |My two cents are that IPFIX runs on top of reliable TCP, hence > |allows exporting large chunk of data. Whereas RMON runs on top > |of UDP, not efficient for large amount of data transporting. I > |may have missed the main points. So any comments are appreciated. > | > |Best regards > |Man Li > | > | > |-- > |Help mailto:majordomo@net.doit.wisc.edu and say "help" > |in message body > |Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > |"unsubscribe ipfix" in message body > |Archive http://ipfix.doit.wisc.edu/archive/ > | -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 5 14:02:35 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13478 for ; Fri, 5 Apr 2002 14:02:35 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16tYYd-00068f-00 for ipfix-list@mil.doit.wisc.edu; Fri, 05 Apr 2002 12:35:31 -0600 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16tYYa-00068W-00 for ipfix@net.doit.wisc.edu; Fri, 05 Apr 2002 12:35:28 -0600 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g35IbvH13393 for ; Fri, 5 Apr 2002 12:37:57 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Apr 2002 12:35:23 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 12:34:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCD0.8B7CB4F0" Subject: RE: [ipfix] ipfix vs. RMON Date: Fri, 5 Apr 2002 13:34:39 -0500 Message-ID: Thread-Topic: [ipfix] ipfix vs. RMON Thread-Index: AcHb+URM5e92dqHdT6eX2J9Iyf8KvAA1I4Eg From: To: , X-OriginalArrivalTime: 05 Apr 2002 18:34:40.0563 (UTC) FILETIME=[8C250830:01C1DCD0] Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------_=_NextPart_001_01C1DCD0.8B7CB4F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Regarding the following two points listed by KC,.=20 RMON - Device statistics and alarms=20 IPFIX - Flow information (IP Flow Information Export)=20 RMON - Health of the device=20 IPFIX - health of the network =20 It seems that RMON2 is also able to collect flow information. For = example, with RFC2819 one can define packet filters for capturing flow = info. Is the main difference then that IPFIX can reliably export large = amount of data whereas RMON being running over SNMP is not able to = handle the volume of data expected? =20 Man ------_=_NextPart_001_01C1DCD0.8B7CB4F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] ipfix vs. RMON
Hi,
 
Regarding the following two points listed by = KC,.

RMON - Device statistics and alarms
IPFIX - Flow information (IP Flow Information Export) =

RMON - Health of the device
IPFIX -=20 health of the network  

It seems=20 that RMON2 is also able to collect flow information. For example, with = RFC2819=20 one can define packet filters for capturing flow=20 info.  Is the main difference then that IPFIX can = reliably export=20 large amount of data whereas RMON being running over SNMP is not able to = handle=20 the volume of data expected?

 

Man

------_=_NextPart_001_01C1DCD0.8B7CB4F0-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 5 14:12:50 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13834 for ; Fri, 5 Apr 2002 14:12:50 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16tYn7-0006Mm-00 for ipfix-list@mil.doit.wisc.edu; Fri, 05 Apr 2002 12:50:29 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16tYn5-0006Ll-00 for ipfix@net.doit.wisc.edu; Fri, 05 Apr 2002 12:50:27 -0600 Received: from riverstonenet.com (134.141.180.94 [134.141.180.94]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H23R7AAF; Fri, 5 Apr 2002 10:48:53 -0800 Message-ID: <3CADF194.809BE07@riverstonenet.com> Date: Fri, 05 Apr 2002 13:48:52 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Man.M.Li@nokia.com CC: knorseth@enterasys.com, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] ipfix vs. RMON References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit That is part of it. Some other items are bulk transfer, implementation with minimal resource needs on the client side in terms of memory and CPU, much more flexible definition of flow in terms of aggregation, etc.. along with standardizing the methods used and defining semantics of data and data operations (i.e. when can you add flow data together). IPFIX encompasses the RMON work so that RMON, I think, could be made to look like an IPFIX device. But we are going beyond what is defined for RMON. IP flow export is not their focus. My 2 cents, Paul Man.M.Li@nokia.com wrote: > > Hi, > > Regarding the following two points listed by KC,. > > RMON - Device statistics and alarms > IPFIX - Flow information (IP Flow Information Export) > > RMON - Health of the device > IPFIX - health of the network > > It seems that RMON2 is also able to collect flow information. For > example, with RFC2819 one can define packet filters for capturing flow > info. Is the main difference then that IPFIX can reliably export > large amount of data whereas RMON being running over SNMP is not able > to handle the volume of data expected? > > > > Man -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 5 14:42:56 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15447 for ; Fri, 5 Apr 2002 14:42:56 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16tZNy-0007Gm-00 for ipfix-list@mil.doit.wisc.edu; Fri, 05 Apr 2002 13:28:34 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16tZNw-0007GH-00 for ipfix@net.doit.wisc.edu; Fri, 05 Apr 2002 13:28:32 -0600 Received: from riverstonenet.com (134.141.180.94 [134.141.180.94]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H23R7AM7; Fri, 5 Apr 2002 11:27:00 -0800 Message-ID: <3CADFA83.C6031D43@riverstonenet.com> Date: Fri, 05 Apr 2002 14:26:59 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Man.M.Li@nokia.com, ipfixx Subject: Re: [ipfix] ipfix vs. RMON References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Man.M.Li@nokia.com wrote: > > Hi, > > See my comments below starting with [man]. I am not defending any of the technologies. But I have a hard time to convince myself the differences between the two, let along to explain to others. I understand. If we can't articulate the differences well, we should! See comments below. > > Man > > -----Original Message----- > From: ext calato@riverstonenet.com [mailto:calato@riverstonenet.com] > Sent: April 05, 2002 01:49 PM > To: Li Man.M (NRC/Boston) > Cc: knorseth@enterasys.com; ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] ipfix vs. RMON > > That is part of it. Some other items are bulk transfer, > implementation with minimal resource needs on the client > side in terms of memory and CPU > > [man] This seems to be an implementation issue rather than IPFIX advantage. Don't underestimate implementation details. That is where success or failure often lays. Design and specification set the boundaries for implementation. So it is an IPFIX advantage because it is being designed so implementation can meet high capacity needs. When I first started doing LFAP on the RS router, I questioned why not RMON as well, but the answer I got for the engineers who knew it best was that it was fine in simple situations but not real world. It would run out of memory, eat up all the CPU, miss information if not polled quickly enough, etc... > > much more flexible > definition of flow in terms of aggregation, > > [man] The RMON packet filter is quite flexible -- one can define the bytes to match in a packet What about deriving data from packet information? the simple one is translating IP address to an AS number. But there are many others. Are those functions standardized? Can you take RMON flows and aggregate them together or can a packet be counted in more than one bucket. What does and RMON do if the box is also doing NAT, can you get/use the before and after fields? Of course there is the reliable transport of data issue along with issues such as failover that come along with that. I'm sure there is more, but at this point I'll let other comment further. > > IPFIX encompasses the RMON work so that RMON, I think, > could be made to look like an IPFIX device. But we are going > beyond what is defined for RMON. > > [man] So the flow monitoring part of RMON is a subset of IPFIX? I would say yes. > > Man.M.Li@nokia.com wrote: > > > > Hi, > > > > Regarding the following two points listed by KC,. > > > > RMON - Device statistics and alarms > > IPFIX - Flow information (IP Flow Information Export) > > > > RMON - Health of the device > > IPFIX - health of the network > > > > It seems that RMON2 is also able to collect flow information. For > > example, with RFC2819 one can define packet filters for capturing flow > > info. Is the main difference then that IPFIX can reliably export > > large amount of data whereas RMON being running over SNMP is not able > > to handle the volume of data expected? > > > > > > > > Man -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 5 17:40:53 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03523 for ; Fri, 5 Apr 2002 17:40:52 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16tcBF-0003FE-00 for ipfix-list@mil.doit.wisc.edu; Fri, 05 Apr 2002 16:27:37 -0600 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16tcBD-0003Ea-00 for ipfix-arch@net.doit.wisc.edu; Fri, 05 Apr 2002 16:27:35 -0600 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g35MQNON026188; Fri, 5 Apr 2002 14:26:23 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-17.cisco.com [171.71.137.17]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABU46920; Fri, 5 Apr 2002 14:26:46 -0800 (PST) Message-ID: <3CAE2485.63C9AAD@cisco.com> Date: Fri, 05 Apr 2002 14:26:13 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: calato@riverstonenet.com CC: Juergen Quittek , knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: <12205450.1017371280@[192.168.102.31]> <3CADB5BA.F3E7D73D@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > > > > > * Template: > > Templates is a set of {type, length} ordered pairs, used to > > completely identify the structure and semantics of a particular > > information that needs to be communicated from the IPFIX Device > > to the collector. Each template is uniquely identified by a > > Template ID. > > This talks solution not req. What if we decided to do it > as a hardcoded record. What if the above line is change to : "Templates is a set of ordered pairs (eg. , TLV), used to... completely identify the structure and semantics of a particular information that needs to be communicated from the IPFIX Device to the collector. Each template is uniquely identifiable by some means (eg. by using a Template ID)." > > > > > > * Control Stream, Data Stream: What was the concern for not using the above terminology - "Stream" ? > > > The information that needs to be exported from the IPFIX device > > can be classified into the following categories: > > > > - Control Information : > > This includes the flow type definition, selection criteria > > for packets within the flow. This is also called as Control > > Stream. Actually the above defintion is not complete. It also includes any control messages like keepalives that gets exchanged between exporter & collector. Basically it is the stream that carries all the information for the end-points to understand the IPFIX protocol and specifically for the receiver to understand and interpret the data stream send by the sender. Does it make sense? > > > - Flow record : > > This includes data records corresponding to the various > > observed flows at each of the observation point. This is also > > called as Data Stream. "This includes data records corresponding to the information on various observed flows at each of the observation point..." BTW I have started to update the arch. spec based on the current inputs from the mailing list. Hope to get an update by mid next week. Thanks Ganesh -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 5 18:22:39 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07527 for ; Fri, 5 Apr 2002 18:22:39 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16tcls-00043a-00 for ipfix-list@mil.doit.wisc.edu; Fri, 05 Apr 2002 17:05:28 -0600 Received: from mailhub.lawrence.edu ([143.44.65.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16tclo-00043Q-00 for ipfix-arch@net.doit.wisc.edu; Fri, 05 Apr 2002 17:05:24 -0600 Received: from lawrence.edu ([143.44.97.41]) by lawrence.edu (PMDF V6.0-025 #44893) with ESMTP id <0GU400MEGBGP6Y@lawrence.edu> for ipfix-arch@net.doit.wisc.edu; Fri, 05 Apr 2002 17:19:37 -0600 (CST) Date: Fri, 05 Apr 2002 17:05:23 -0600 From: Robert Lowe Subject: Re: [ipfix-arch] revised terminology To: Ganesh Sadasivan Cc: calato@riverstonenet.com, Juergen Quittek , knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Message-id: <3CAE2DB3.3BE698DB@lawrence.edu> Organization: Lawrence University MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <12205450.1017371280@[192.168.102.31]> <3CADB5BA.F3E7D73D@riverstonenet.com> <3CAE2485.63C9AAD@cisco.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh Sadasivan wrote: > > > > > > > > > * Template: > > > Templates is a set of {type, length} ordered pairs, used to > > > completely identify the structure and semantics of a particular > > > information that needs to be communicated from the IPFIX Device > > > to the collector. Each template is uniquely identified by a > > > Template ID. > > > > This talks solution not req. What if we decided to do it > > as a hardcoded record. > > What if the above line is change to : > "Templates is a set of ordered pairs (eg. , TLV), used to... > completely identify the structure and semantics of a particular > information that needs to be communicated from the IPFIX Device > to the collector. Each template is uniquely identifiable by some means > (eg. by using a Template ID)." > > > > > > > > > > > * Control Stream, Data Stream: > > What was the concern for not using the above terminology - > "Stream" ? See http://ipfix.doit.wisc.edu/archive/0849.html (both contol and stream were found objectionable): The architecture document currently refers to separate control and data streams. The control stream being a reliable path to exchange control information, monitor connectivity and other failures, and the data stream to send the IPFIX export payload itself. At this point, a number of attendees took issue with the use of the word "control" because it can be confusing. In response it was noted that, in this context, "control [information]" refers to the portion of IPFIX which communicates the structure of the exported data. Consensus was that both the words "control" and "stream" are inappropriate. "Data description" was suggested as an alternative. I also noted the following... Also, the chairs said that explicit references to template-based application-level protocols need to be removed from the architecture document, since the IPFIX requirements do not exclude other candidate self-describing data encoding methods. ...but I'm not sure if that applies to what is mentioned above. -Robert > > > > > The information that needs to be exported from the IPFIX device > > > can be classified into the following categories: > > > > > > - Control Information : > > > This includes the flow type definition, selection criteria > > > for packets within the flow. This is also called as Control > > > Stream. > > Actually the above defintion is not complete. It also includes any control messages > > like keepalives that gets exchanged between exporter & collector. Basically > it is the stream that carries all the information for the end-points to understand > the IPFIX protocol and specifically for the receiver to understand and interpret > the data stream send by the sender. Does it make sense? > > > > > > - Flow record : > > > This includes data records corresponding to the various > > > observed flows at each of the observation point. This is also > > > called as Data Stream. > > "This includes data records corresponding to the information on various > observed flows at each of the observation point..." > > BTW I have started to update the arch. spec based on the current inputs > from the mailing list. Hope to get an update by mid next week. > > Thanks > Ganesh > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 5 18:23:31 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07689 for ; Fri, 5 Apr 2002 18:23:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16tcna-00046F-00 for ipfix-list@mil.doit.wisc.edu; Fri, 05 Apr 2002 17:07:14 -0600 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16tcnY-00045K-00 for ipfix-arch@net.doit.wisc.edu; Fri, 05 Apr 2002 17:07:13 -0600 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g35N6aON016350; Fri, 5 Apr 2002 15:06:36 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-17.cisco.com [171.71.137.17]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABU48410; Fri, 5 Apr 2002 15:07:07 -0800 (PST) Message-ID: <3CAE2DFA.26B1ECD9@cisco.com> Date: Fri, 05 Apr 2002 15:06:34 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-arch@net.doit.wisc.edu, calato@riverstonenet.com Subject: Re: observation point limits (was: Re: [ipfix-arch] revised terminology) References: <3CAB9C2A.7226EF33@cisco.com> <3095961.1017913338@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Jurgene, Here are my thougts. Juergen Quittek wrote: > Ganesh, > > Yes, that's the point: > > What - or where - is the IPFIX boundary? > Is the maximum level of aggregation a single device? Yes. I mean an observation domain should not span multiple network devices. Atleast I do not know of a concerete example as to why it should be otherwise. > > > What is the largest observation point? The largest aggregatable interface defined by the network device. This may be a single interface, a set of interfaces or a logical interface as far as the network device is concerned. I do not disagree with Paul's idea of heirarchical observation points. But can't this be done outside the IPFIX device. > > Or: What is the largest set of observation points out of > which observed packets may be aggregated into a single flow? The set of all observation points within an observation domain. > > > - single interface of a single device > - set of interfaces of a single device > - all interfaces of a device Yes cut below. > > ----------------- cut? ------------------ > - several devices > - entire network Thanks Ganesh -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 5 18:34:31 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08865 for ; Fri, 5 Apr 2002 18:34:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16td0T-0004Pj-00 for ipfix-list@mil.doit.wisc.edu; Fri, 05 Apr 2002 17:20:33 -0600 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16td0R-0004Oa-00 for ipfix-arch@net.doit.wisc.edu; Fri, 05 Apr 2002 17:20:31 -0600 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g35NJCMY010302; Fri, 5 Apr 2002 15:19:12 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-17.cisco.com [171.71.137.17]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABU48828; Fri, 5 Apr 2002 15:19:44 -0800 (PST) Message-ID: <3CAE30EF.5C93E889@cisco.com> Date: Fri, 05 Apr 2002 15:19:12 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Lowe CC: calato@riverstonenet.com, Juergen Quittek , knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: <12205450.1017371280@[192.168.102.31]> <3CADB5BA.F3E7D73D@riverstonenet.com> <3CAE2485.63C9AAD@cisco.com> <3CAE2DB3.3BE698DB@lawrence.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Robert Lowe wrote: > Ganesh Sadasivan wrote: > > > > > > > > > > > > > * Template: > > > > Templates is a set of {type, length} ordered pairs, used to > > > > completely identify the structure and semantics of a particular > > > > information that needs to be communicated from the IPFIX Device > > > > to the collector. Each template is uniquely identified by a > > > > Template ID. > > > > > > This talks solution not req. What if we decided to do it > > > as a hardcoded record. > > > > What if the above line is change to : > > "Templates is a set of ordered pairs (eg. , TLV), used to... > > completely identify the structure and semantics of a particular > > information that needs to be communicated from the IPFIX Device > > to the collector. Each template is uniquely identifiable by some means > > (eg. by using a Template ID)." > > > > > > > > > > > > > > > > * Control Stream, Data Stream: > > > > What was the concern for not using the above terminology - > > "Stream" ? > > See http://ipfix.doit.wisc.edu/archive/0849.html (both contol and stream > were found objectionable): > > The architecture document currently refers to separate control and > data streams. The control stream being a reliable path to exchange > control information, monitor connectivity and other failures, and > the data stream to send the IPFIX export payload itself. > > At this point, a number of attendees took issue with the use of the > word "control" because it can be confusing. In response it was > noted that, in this context, "control [information]" refers to the > portion of IPFIX which communicates the structure of the exported > data. > > Consensus was that both the words "control" and "stream" are > inappropriate. "Data description" was suggested as an alternative. "Data description" is not the correct alternative. It covers only a subset of information that is being referred to. As I mentioned below, this covers other messages like keepalives etc. I can't think of a better word than "control stream" as of now. Suggest people from the mailing list to provide a better name. > > > I also noted the following... > > Also, the chairs said that explicit references to template-based > application-level protocols need to be removed from the architecture > document, since the IPFIX requirements do not exclude other > candidate self-describing data encoding methods. This is being done. So what do you think about the above definition change to template? Ganesh > > > ...but I'm not sure if that applies to what is mentioned above. > > -Robert > > > > > > > > The information that needs to be exported from the IPFIX device > > > > can be classified into the following categories: > > > > > > > > - Control Information : > > > > This includes the flow type definition, selection criteria > > > > for packets within the flow. This is also called as Control > > > > Stream. > > > > Actually the above defintion is not complete. It also includes any control messages > > > > like keepalives that gets exchanged between exporter & collector. Basically > > it is the stream that carries all the information for the end-points to understand > > the IPFIX protocol and specifically for the receiver to understand and interpret > > the data stream send by the sender. Does it make sense? > > > > > > > > > - Flow record : > > > > This includes data records corresponding to the various > > > > observed flows at each of the observation point. This is also > > > > called as Data Stream. > > > > "This includes data records corresponding to the information on various > > observed flows at each of the observation point..." > > > > BTW I have started to update the arch. spec based on the current inputs > > from the mailing list. Hope to get an update by mid next week. > > > > Thanks > > Ganesh > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 5 18:53:54 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10711 for ; Fri, 5 Apr 2002 18:53:54 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16tdIM-0004mG-00 for ipfix-list@mil.doit.wisc.edu; Fri, 05 Apr 2002 17:39:02 -0600 Received: from mailhub.lawrence.edu ([143.44.65.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16tdIK-0004m5-00 for ipfix-arch@net.doit.wisc.edu; Fri, 05 Apr 2002 17:39:00 -0600 Received: from lawrence.edu ([143.44.97.41]) by lawrence.edu (PMDF V6.0-025 #44893) with ESMTP id <0GU4004E4D0O3G@lawrence.edu> for ipfix-arch@net.doit.wisc.edu; Fri, 05 Apr 2002 17:53:13 -0600 (CST) Date: Fri, 05 Apr 2002 17:38:59 -0600 From: Robert Lowe Subject: Re: [ipfix-arch] revised terminology To: Ganesh Sadasivan Cc: calato@riverstonenet.com, Juergen Quittek , knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Message-id: <3CAE3593.2C598269@lawrence.edu> Organization: Lawrence University MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <12205450.1017371280@[192.168.102.31]> <3CADB5BA.F3E7D73D@riverstonenet.com> <3CAE2485.63C9AAD@cisco.com> <3CAE2DB3.3BE698DB@lawrence.edu> <3CAE30EF.5C93E889@cisco.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh Sadasivan wrote: > > Robert Lowe wrote: > > > Ganesh Sadasivan wrote: > > > > > > > > > > > > > > > > > * Template: > > > > > Templates is a set of {type, length} ordered pairs, used to > > > > > completely identify the structure and semantics of a particular > > > > > information that needs to be communicated from the IPFIX Device > > > > > to the collector. Each template is uniquely identified by a > > > > > Template ID. > > > > > > > > This talks solution not req. What if we decided to do it > > > > as a hardcoded record. > > > > > > What if the above line is change to : > > > "Templates is a set of ordered pairs (eg. , TLV), used to... > > > completely identify the structure and semantics of a particular > > > information that needs to be communicated from the IPFIX Device > > > to the collector. Each template is uniquely identifiable by some means > > > (eg. by using a Template ID)." > > > > > > > > > > > > > > > > > > > > > * Control Stream, Data Stream: > > > > > > What was the concern for not using the above terminology - > > > "Stream" ? > > > > See http://ipfix.doit.wisc.edu/archive/0849.html (both contol and stream > > were found objectionable): > > > > The architecture document currently refers to separate control and > > data streams. The control stream being a reliable path to exchange > > control information, monitor connectivity and other failures, and > > the data stream to send the IPFIX export payload itself. > > > > At this point, a number of attendees took issue with the use of the > > word "control" because it can be confusing. In response it was > > noted that, in this context, "control [information]" refers to the > > portion of IPFIX which communicates the structure of the exported > > data. > > > > Consensus was that both the words "control" and "stream" are > > inappropriate. "Data description" was suggested as an alternative. > > "Data description" is not the correct alternative. It covers only a subset > of information that is being referred to. As I mentioned below, this > covers other messages like keepalives etc. I can't think of a better word than > "control stream" as of now. Suggest people from the mailing list to provide > a better name. Well, how about "operational messaging something-or-other" -- and I am shooting in the dark here. :) What's the something-or-other though? Not link, and if not stream, can it be a flow? > > > > > > I also noted the following... > > > > Also, the chairs said that explicit references to template-based > > application-level protocols need to be removed from the architecture > > document, since the IPFIX requirements do not exclude other > > candidate self-describing data encoding methods. > > This is being done. So what do you think about the above definition > change to template? Other than a couple of agreement errors, it seems fine to me. -Robert > Ganesh > > > > > > > ...but I'm not sure if that applies to what is mentioned above. > > > > -Robert > > > > > > > > > > > The information that needs to be exported from the IPFIX device > > > > > can be classified into the following categories: > > > > > > > > > > - Control Information : > > > > > This includes the flow type definition, selection criteria > > > > > for packets within the flow. This is also called as Control > > > > > Stream. > > > > > > Actually the above defintion is not complete. It also includes any control messages > > > > > > like keepalives that gets exchanged between exporter & collector. Basically > > > it is the stream that carries all the information for the end-points to understand > > > the IPFIX protocol and specifically for the receiver to understand and interpret > > > the data stream send by the sender. Does it make sense? > > > > > > > > > > > > - Flow record : > > > > > This includes data records corresponding to the various > > > > > observed flows at each of the observation point. This is also > > > > > called as Data Stream. > > > > > > "This includes data records corresponding to the information on various > > > observed flows at each of the observation point..." > > > > > > BTW I have started to update the arch. spec based on the current inputs > > > from the mailing list. Hope to get an update by mid next week. > > > > > > Thanks > > > Ganesh > > > > > > -- > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > "unsubscribe ipfix" in message body > > > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Apr 9 03:33:47 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28412 for ; Tue, 9 Apr 2002 03:33:47 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16upcN-0007iJ-00 for ipfix-list@mil.doit.wisc.edu; Tue, 09 Apr 2002 02:00:39 -0500 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16upcK-0007gR-00 for ipfix-arch@net.doit.wisc.edu; Tue, 09 Apr 2002 02:00:36 -0500 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g396xNON013926; Mon, 8 Apr 2002 23:59:23 -0700 (PDT) Received: from cisco.com (dhcp-171-71-137-26.cisco.com [171.71.137.26]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABW41297; Mon, 8 Apr 2002 23:59:57 -0700 (PDT) Message-ID: <3CB2914A.C1A084AE@cisco.com> Date: Mon, 08 Apr 2002 23:59:22 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Lowe CC: calato@riverstonenet.com, Juergen Quittek , knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: <12205450.1017371280@[192.168.102.31]> <3CADB5BA.F3E7D73D@riverstonenet.com> <3CAE2485.63C9AAD@cisco.com> <3CAE2DB3.3BE698DB@lawrence.edu> <3CAE30EF.5C93E889@cisco.com> <3CAE3593.2C598269@lawrence.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > > > > > > > Consensus was that both the words "control" and "stream" are > > > inappropriate. "Data description" was suggested as an alternative. > > > > "Data description" is not the correct alternative. It covers only a subset > > of information that is being referred to. As I mentioned below, this > > covers other messages like keepalives etc. I can't think of a better word than > > "control stream" as of now. Suggest people from the mailing list to provide > > a better name. > > Well, how about "operational messaging something-or-other" -- and I am shooting > in the dark here. :) What's the something-or-other though? Not link, and > if not stream, can it be a flow? I am not satisfied. > > > > > > > > > > > I also noted the following... > > > > > > Also, the chairs said that explicit references to template-based > > > application-level protocols need to be removed from the architecture > > > document, since the IPFIX requirements do not exclude other > > > candidate self-describing data encoding methods. > > > > This is being done. So what do you think about the above definition > > change to template? > > Other than a couple of agreement errors, it seems fine to me. What do you mean by "agreement errors"? Ganesh > > > -Robert > > > Ganesh > > > > > > > > > > > ...but I'm not sure if that applies to what is mentioned above. > > > > > > -Robert > > > > > > > > > > > > > > The information that needs to be exported from the IPFIX device > > > > > > can be classified into the following categories: > > > > > > > > > > > > - Control Information : > > > > > > This includes the flow type definition, selection criteria > > > > > > for packets within the flow. This is also called as Control > > > > > > Stream. > > > > > > > > Actually the above defintion is not complete. It also includes any control messages > > > > > > > > like keepalives that gets exchanged between exporter & collector. Basically > > > > it is the stream that carries all the information for the end-points to understand > > > > the IPFIX protocol and specifically for the receiver to understand and interpret > > > > the data stream send by the sender. Does it make sense? > > > > > > > > > > > > > > > - Flow record : > > > > > > This includes data records corresponding to the various > > > > > > observed flows at each of the observation point. This is also > > > > > > called as Data Stream. > > > > > > > > "This includes data records corresponding to the information on various > > > > observed flows at each of the observation point..." > > > > > > > > BTW I have started to update the arch. spec based on the current inputs > > > > from the mailing list. Hope to get an update by mid next week. > > > > > > > > Thanks > > > > Ganesh > > > > > > > > -- > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > > "unsubscribe ipfix" in message body > > > > Archive http://ipfix.doit.wisc.edu/archive/ > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Apr 9 18:08:05 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24507 for ; Tue, 9 Apr 2002 18:08:04 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16v3Mz-0006Dq-00 for ipfix-list@mil.doit.wisc.edu; Tue, 09 Apr 2002 16:41:41 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.us.nortel.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16v3My-0006Dc-00 for ipfix@net.doit.wisc.edu; Tue, 09 Apr 2002 16:41:40 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g39LfD324214 for ; Tue, 9 Apr 2002 14:41:13 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXM752D>; Tue, 9 Apr 2002 14:41:07 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C01D86500@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: ipfix@net.doit.wisc.edu Subject: [ipfix] New draft available? Date: Tue, 9 Apr 2002 14:41:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E00F.3F3C48F2" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E00F.3F3C48F2 Content-Type: text/plain; charset="iso-8859-1" Hello, are there some new versions of the draft availble or -00 is still the most current? thanks, Reinaldo ------_=_NextPart_001_01C1E00F.3F3C48F2 Content-Type: text/html; charset="iso-8859-1" New draft available?

Hello,

are there some new versions of the draft availble or -00 is still the most current?

thanks,

Reinaldo

------_=_NextPart_001_01C1E00F.3F3C48F2-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Apr 9 18:15:19 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24614 for ; Tue, 9 Apr 2002 18:15:19 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16v3Zm-0006Tk-00 for ipfix-list@mil.doit.wisc.edu; Tue, 09 Apr 2002 16:54:54 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.us.nortel.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16v3Zk-0006T3-00 for ipfix-data@net.doit.wisc.edu; Tue, 09 Apr 2002 16:54:52 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g39Lo1324717; Tue, 9 Apr 2002 14:50:01 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXM75ML>; Tue, 9 Apr 2002 14:49:55 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C01D86529@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: "Norseth, KC" , calato@riverstonenet.com Cc: ipfix-data@net.doit.wisc.edu Subject: [ipfix-data] Data doc - Section 7.11 Date: Tue, 9 Apr 2002 14:49:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E010.7B702932" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E010.7B702932 Content-Type: text/plain; charset="iso-8859-1" In the data doc there was a part that Paul disagrees (or used to) with me. I'm okay with finding other names anyway, but IMO the description is better this way Basically I wanted to change section on NAT/source virtual/destination virtual to: 7.11. Middlebox and other Services An exporter may be involved in providing services that require application level intelligence and/or transform or filter content such as middlebox and OPES respectively. When the exporter is involved on these types of services the order of the IEs that contain information associated with these service MUST reflect the order of the operations performed. Each type field of the following IEs contain the type of operation performed on the packet. The currently available types are: 1. - NAT 2. - LSNAT 3. - Twice NAT 4. - Request Routing [KRR] 5. - Outgoing L3 Tunnel 6. - Incoming L3 Tunnel 7. - Outgoing L2 Tunnel 8. - Incoming L2 Tunnel 9. - OPES (several sub-services here) 10. - others... 6.12.1. Modified Source Address This information element contains the source address of the flow as transmitted by the Exporter after a middlebox, OPES or similar service was applied to the packet. It may be different than the source address information element, which contains the original source address of the packet. The address is defined the same as for Source Address. Template ID: ### Field Type: ### Size: ### 6.12.2. Modified Source Port This information element contains the source port of the flow as transmitted by the exporter after a middlebox, OPES or similar service was applied to the packet. It may be different than the source port information element, which contains the original source port of the packet. Template ID: ### Field Type: ### Size: ### 6.12.3. Modified Destination Address This information element contains the destination address of the flow as transmitted by the exporter after a middlebox, OPES or similar service was applied to the packet. It might be different than the destination address information element, which contains the original destination address of the packet. Template ID: ### Field Type: ### Size: ### 6.12.4. Destination Virtual Port This information element contains the destination port of the flow as transmitted by the exporter after a middlebox, OPES or similar service was applied to the packet. It may be different than the destination port information element, which contains the original destination port of the packet. Template ID: ### Field Type: ### Size: ### ------_=_NextPart_001_01C1E010.7B702932 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Data doc - Section 7.11

In the data doc there was a part that Paul disagrees = (or used to) with me. I'm okay with finding other names anyway, but IMO = the description is better this way

Basically I wanted to change section on NAT/source = virtual/destination virtual to:

7.11. Middlebox and other Services

An exporter may be involved in providing services = that require
application level intelligence and/or transform or = filter content such
as middlebox and OPES respectively.

When the exporter is involved on these types of = services the order of
the IEs that contain information associated with = these service MUST
reflect the order of the operations = performed.

Each type field of the following IEs contain the type = of operation
performed on the packet. The currently available = types are:

1. - NAT
2. - LSNAT
3. - Twice NAT
4. - Request Routing [KRR]
5. - Outgoing L3 Tunnel
6. - Incoming L3 Tunnel
7. - Outgoing L2 Tunnel
8. - Incoming L2 Tunnel
9. - OPES (several sub-services here)
10. - others...

6.12.1.  Modified Source Address

This information element contains the source address = of the flow as
transmitted by the Exporter after a middlebox, OPES = or similar service
was applied to the packet. It may be different than = the source address
information element, which contains the original = source address of the packet.

The address is defined the same as for Source = Address.

Template ID: ###   Field Type: = ###   Size: ###

6.12.2.  Modified Source Port

This information element contains the source port of = the flow as
transmitted by the exporter after a middlebox, OPES = or similar service
was applied to the packet. It may be different than = the source port
information element, which contains the original = source port of the packet. 

Template ID: ###   Field Type: = ###   Size: ###


6.12.3.  Modified Destination Address

This information element contains the destination = address of the flow
as transmitted by the exporter after a middlebox, = OPES or similar
service was applied to the packet. It might be = different than the
destination address information element, which = contains the original
destination address of the packet.

Template ID: ###   Field Type: = ###   Size: ###


6.12.4.  Destination Virtual Port

This information element contains the destination = port of the flow as
transmitted by the exporter after a middlebox, OPES = or similar service
was applied to the packet. It may be different than = the destination
port information element, which contains the = original destination port
of the packet. 

Template ID: ###   Field Type: = ###   Size: ###

------_=_NextPart_001_01C1E010.7B702932-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Apr 9 18:56:26 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25142 for ; Tue, 9 Apr 2002 18:56:26 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16v4L2-0007Ys-00 for ipfix-list@mil.doit.wisc.edu; Tue, 09 Apr 2002 17:43:44 -0500 Received: from mailhub.lawrence.edu ([143.44.65.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16v4L0-0007Ym-00 for ipfix-arch@net.doit.wisc.edu; Tue, 09 Apr 2002 17:43:42 -0500 Received: from lawrence.edu ([143.44.97.41]) by lawrence.edu (PMDF V6.0-025 #44893) with ESMTP id <0GUB0072MP4RBB@lawrence.edu> for ipfix-arch@net.doit.wisc.edu; Tue, 09 Apr 2002 17:58:04 -0500 (CDT) Date: Tue, 09 Apr 2002 17:43:43 -0500 From: Robert Lowe Subject: Re: [ipfix-arch] revised terminology To: Ganesh Sadasivan Cc: calato@riverstonenet.com, Juergen Quittek , knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Message-id: <3CB36E9F.2227C7B5@lawrence.edu> Organization: Lawrence University MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <12205450.1017371280@[192.168.102.31]> <3CADB5BA.F3E7D73D@riverstonenet.com> <3CAE2485.63C9AAD@cisco.com> <3CAE2DB3.3BE698DB@lawrence.edu> <3CAE30EF.5C93E889@cisco.com> <3CAE3593.2C598269@lawrence.edu> <3CB2914A.C1A084AE@cisco.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh Sadasivan wrote: > > > > > > > > > > > Consensus was that both the words "control" and "stream" are > > > > inappropriate. "Data description" was suggested as an alternative. > > > > > > "Data description" is not the correct alternative. It covers only a subset > > > of information that is being referred to. As I mentioned below, this > > > covers other messages like keepalives etc. I can't think of a better word than > > > "control stream" as of now. Suggest people from the mailing list to provide > > > a better name. > > > > Well, how about "operational messaging something-or-other" -- and I am shooting > > in the dark here. :) What's the something-or-other though? Not link, and > > if not stream, can it be a flow? > > I am not satisfied. I did say I was shooting in the dark! Any other suggestions then? Its purpose is operational, i.e. information passed between IPFIX devices and IPFIX collectors, so that is just another word for "control". Why was "stream" objectionable? What connotation was deemed inappropriate? What about "control"? (I wasn't there.) If it was mostly "stream" that was objectionable, then borrow parts of the acronym ICMP that are appropriate, if not the whole thing. :) Keepalives fit that model anyhow. > > > > > > > > > > > > > > > > I also noted the following... > > > > > > > > Also, the chairs said that explicit references to template-based > > > > application-level protocols need to be removed from the architecture > > > > document, since the IPFIX requirements do not exclude other > > > > candidate self-describing data encoding methods. > > > > > > This is being done. So what do you think about the above definition > > > change to template? > > > > Other than a couple of agreement errors, it seems fine to me. > > What do you mean by "agreement errors"? Just English stuff... subject and verb tense (templates is...), or the use of "information". -Robert -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Apr 9 20:42:25 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26544 for ; Tue, 9 Apr 2002 20:42:25 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16v5wc-0001zf-00 for ipfix-list@mil.doit.wisc.edu; Tue, 09 Apr 2002 19:26:38 -0500 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16v5wa-0001z0-00 for ipfix-arch@net.doit.wisc.edu; Tue, 09 Apr 2002 19:26:36 -0500 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3A0PNON010049; Tue, 9 Apr 2002 17:25:23 -0700 (PDT) Received: from cisco.com (dhcp-171-71-137-26.cisco.com [171.71.137.26]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABW68670; Tue, 9 Apr 2002 17:25:57 -0700 (PDT) Message-ID: <3CB38672.DF672C2C@cisco.com> Date: Tue, 09 Apr 2002 17:25:22 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Lowe CC: calato@riverstonenet.com, Juergen Quittek , knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: <12205450.1017371280@[192.168.102.31]> <3CADB5BA.F3E7D73D@riverstonenet.com> <3CAE2485.63C9AAD@cisco.com> <3CAE2DB3.3BE698DB@lawrence.edu> <3CAE30EF.5C93E889@cisco.com> <3CAE3593.2C598269@lawrence.edu> <3CB2914A.C1A084AE@cisco.com> <3CB36E9F.2227C7B5@lawrence.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Robert Lowe wrote: > Ganesh Sadasivan wrote: > > > > > > > > > > > > > > > Consensus was that both the words "control" and "stream" are > > > > > inappropriate. "Data description" was suggested as an alternative. > > > > > > > > "Data description" is not the correct alternative. It covers only a subset > > > > of information that is being referred to. As I mentioned below, this > > > > covers other messages like keepalives etc. I can't think of a better word than > > > > "control stream" as of now. Suggest people from the mailing list to provide > > > > a better name. > > > > > > Well, how about "operational messaging something-or-other" -- and I am shooting > > > in the dark here. :) What's the something-or-other though? Not link, and > > > if not stream, can it be a flow? > > > > I am not satisfied. > > I did say I was shooting in the dark! Any other suggestions then? > > Its purpose is operational, i.e. information passed between IPFIX devices > and IPFIX collectors, so that is just another word for "control". True it carries operational information - (protocol + meta-data). > > > Why was "stream" objectionable? What connotation was deemed inappropriate? > What about "control"? (I wasn't there.) If it was mostly "stream" that was I guess people felt that "control" carries only the meta-data which is not correct. Why not "stream" - "meta-data" could potentially be mixed with flow records and may not be separable into a stream. But we are talking about a conceptual view. Still not suggesting any new term... Ganesh > > objectionable, then borrow parts of the acronym ICMP that are appropriate, if > not the whole thing. :) Keepalives fit that model anyhow. > > > > > > > > > > > > > > > > > > > > > > I also noted the following... > > > > > > > > > > Also, the chairs said that explicit references to template-based > > > > > application-level protocols need to be removed from the architecture > > > > > document, since the IPFIX requirements do not exclude other > > > > > candidate self-describing data encoding methods. > > > > > > > > This is being done. So what do you think about the above definition > > > > change to template? > > > > > > Other than a couple of agreement errors, it seems fine to me. > > > > What do you mean by "agreement errors"? > > Just English stuff... subject and verb tense (templates is...), or the use > of "information". > > -Robert -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Apr 10 03:58:12 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13293 for ; Wed, 10 Apr 2002 03:58:12 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16vCgG-0003Jr-00 for ipfix-list@mil.doit.wisc.edu; Wed, 10 Apr 2002 02:38:12 -0500 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16vCgD-0003J4-00 for ipfix@net.doit.wisc.edu; Wed, 10 Apr 2002 02:38:09 -0500 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3A7bbq6006551; Wed, 10 Apr 2002 00:37:37 -0700 (PDT) Received: from cisco.com (dhcp-171-71-137-26.cisco.com [171.71.137.26]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABW77287; Wed, 10 Apr 2002 00:38:11 -0700 (PDT) Message-ID: <3CB3EBC0.2E24A66D@cisco.com> Date: Wed, 10 Apr 2002 00:37:37 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] New draft available? References: <7B802811BE77D51189910002A55CFD2C01D86500@zsc3c032.us.nortel.com> Content-Type: multipart/alternative; boundary="------------F07C699DA93F3011321878E3" Precedence: bulk Sender: majordomo listserver --------------F07C699DA93F3011321878E3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rienaldo, -01 arch. spec will come out in a few days. Ganesh Reinaldo Penno wrote: > > > Hello, > > are there some new versions of the draft availble or -00 is still the > most current? > > thanks, > > Reinaldo --------------F07C699DA93F3011321878E3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Rienaldo,

-01 arch. spec will come out in a few days.
Ganesh

Reinaldo Penno wrote:

 

Hello,

are there some new versions of the draft availble or -00 is still the most current?

thanks,

Reinaldo

--------------F07C699DA93F3011321878E3-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 12 07:46:02 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10956 for ; Fri, 12 Apr 2002 07:46:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16vzDJ-0000HR-00 for ipfix-list@mil.doit.wisc.edu; Fri, 12 Apr 2002 06:27:33 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16vzDH-0000GO-00 for ipfix-data@net.doit.wisc.edu; Fri, 12 Apr 2002 06:27:31 -0500 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g3CBQx857359; Fri, 12 Apr 2002 13:26:59 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA02934; Fri, 12 Apr 2002 13:26:15 +0200 Date: Fri, 12 Apr 2002 13:30:08 +0200 From: Juergen Quittek To: Reinaldo Penno , "Norseth, KC" , calato@riverstonenet.com cc: ipfix-data@net.doit.wisc.edu Subject: Re: [ipfix-data] Data doc - Section 7.11 Message-ID: <20891760.1018618208@[192.168.102.164]> In-Reply-To: <7B802811BE77D51189910002A55CFD2C01D86529@zsc3c032.us.nortel.com> References: <7B802811BE77D51189910002A55CFD2C01D86529@zsc3c032.us.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Reinaldo, --On 09 April 2002 14:49 -0700 Reinaldo Penno wrote: > > In the data doc there was a part that Paul disagrees (or used to) with me. I'm okay with finding other names anyway, but IMO the description is better this way > > Basically I wanted to change section on NAT/source virtual/destination virtual to: > > 7.11. Middlebox and other Services Having to choose between "Virtual Information" and "Middlebox and other Services", I prefer the first one, because it is as general as "other services" and it better reflects a meter's view: It does not care that much about functions and applications/services running additionally on the same box, it just cares about what such applications do with packets or beterr with packet headers. Then the concept of virtual and actual values of header fields seem so be an adequate and sufficient view of what is happening. > > An exporter may be involved in providing services that require > application level intelligence and/or transform or filter content such I don't think there will be any router or other exporter device that deserves the attribute 'intelligent'. These boxes are SO dumb! Just work with them and you'll see :-) > as middlebox and OPES respectively. > > When the exporter is involved on these types of services the order of > the IEs that contain information associated with these service MUST > reflect the order of the operations performed. No. We should not have a MUST here. This would mean that you cannot add middlebox functions to your box without updating the IPFIX software/hardware. You could not run the same implementation on boxes with different functionality. It is nice if the IPFIX device reflects middlebox functions, but a MAY should be appropriate. > > Each type field of the following IEs contain the type of operation > performed on the packet. The currently available types are: > > 1. - NAT > 2. - LSNAT > 3. - Twice NAT > 4. - Request Routing [KRR] > 5. - Outgoing L3 Tunnel > 6. - Incoming L3 Tunnel > 7. - Outgoing L2 Tunnel > 8. - Incoming L2 Tunnel > 9. - OPES (several sub-services here) > 10. - others... > > 6.12.1. Modified Source Address > > This information element contains the source address of the flow as > transmitted by the Exporter after a middlebox, OPES or similar service What is a OPES similar service? This is rather unclear, particularly if you request a MUST to support it. I prefer Paul's term 'redirecting packets/flows'. Juergen > was applied to the packet. It may be different than the source address > information element, which contains the original source address of the packet. > > The address is defined the same as for Source Address. > > Template ID: ### Field Type: ### Size: ### > > 6.12.2. Modified Source Port > > This information element contains the source port of the flow as > transmitted by the exporter after a middlebox, OPES or similar service > was applied to the packet. It may be different than the source port > information element, which contains the original source port of the packet. > > Template ID: ### Field Type: ### Size: ### > > 6.12.3. Modified Destination Address > > This information element contains the destination address of the flow > as transmitted by the exporter after a middlebox, OPES or similar > service was applied to the packet. It might be different than the > destination address information element, which contains the original > destination address of the packet. > > Template ID: ### Field Type: ### Size: ### > > 6.12.4. Destination Virtual Port > > This information element contains the destination port of the flow as > transmitted by the exporter after a middlebox, OPES or similar service > was applied to the packet. It may be different than the destination > port information element, which contains the original destination port > of the packet. > > Template ID: ### Field Type: ### Size: ### -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 12 09:23:12 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20211 for ; Fri, 12 Apr 2002 09:23:11 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16w0op-0002al-00 for ipfix-list@mil.doit.wisc.edu; Fri, 12 Apr 2002 08:10:23 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16w0on-0002aC-00 for ipfix-arch@net.doit.wisc.edu; Fri, 12 Apr 2002 08:10:21 -0500 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-163.cisco.com [144.254.7.163]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id PAA19868; Fri, 12 Apr 2002 15:08:57 +0200 (MET DST) Message-ID: <3CB6DC69.6020203@cisco.com> Date: Fri, 12 Apr 2002 15:08:57 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ganesh Sadasivan , kevin.zhang@xacct.com CC: Robert Lowe , calato@riverstonenet.com, Juergen Quittek , knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: <12205450.1017371280@[192.168.102.31]> <3CADB5BA.F3E7D73D@riverstonenet.com> <3CAE2485.63C9AAD@cisco.com> <3CAE2DB3.3BE698DB@lawrence.edu> <3CAE30EF.5C93E889@cisco.com> <3CAE3593.2C598269@lawrence.edu> <3CB2914A.C1A084AE@cisco.com> <3CB36E9F.2227C7B5@lawrence.edu> <3CB38672.DF672C2C@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit All, I've been thinking about this term "control stream". I couldn't find a better term. I'm proposing that the people who were objecting at the last IETF meeting propose a better term; I'm remembering of Kevin Zhang (maybe some others). Kevin, do you have a better wording? Regards, Benoit > >Robert Lowe wrote: > >>Ganesh Sadasivan wrote: >> >>>>>> Consensus was that both the words "control" and "stream" are >>>>>> inappropriate. "Data description" was suggested as an alternative. >>>>>> >>>>>"Data description" is not the correct alternative. It covers only a subset >>>>>of information that is being referred to. As I mentioned below, this >>>>>covers other messages like keepalives etc. I can't think of a better word than >>>>>"control stream" as of now. Suggest people from the mailing list to provide >>>>>a better name. >>>>> >>>>Well, how about "operational messaging something-or-other" -- and I am shooting >>>>in the dark here. :) What's the something-or-other though? Not link, and >>>>if not stream, can it be a flow? >>>> >>>I am not satisfied. >>> >>I did say I was shooting in the dark! Any other suggestions then? >> >>Its purpose is operational, i.e. information passed between IPFIX devices >>and IPFIX collectors, so that is just another word for "control". >> > >True it carries operational information - (protocol + meta-data). > >> >>Why was "stream" objectionable? What connotation was deemed inappropriate? >>What about "control"? (I wasn't there.) If it was mostly "stream" that was >> > >I guess people felt that "control" carries only the meta-data which is >not correct. Why not "stream" - "meta-data" could potentially be mixed with >flow records and may not be separable into a stream. But we are talking >about a conceptual view. >Still not suggesting any new term... >Ganesh > >>objectionable, then borrow parts of the acronym ICMP that are appropriate, if >>not the whole thing. :) Keepalives fit that model anyhow. >> >>>> >>>>>> >>>>>>I also noted the following... >>>>>> >>>>>> Also, the chairs said that explicit references to template-based >>>>>> application-level protocols need to be removed from the architecture >>>>>> document, since the IPFIX requirements do not exclude other >>>>>> candidate self-describing data encoding methods. >>>>>> >>>>>This is being done. So what do you think about the above definition >>>>>change to template? >>>>> >>>>Other than a couple of agreement errors, it seems fine to me. >>>> >>>What do you mean by "agreement errors"? >>> >>Just English stuff... subject and verb tense (templates is...), or the use >>of "information". >> >>-Robert >> > > >-- >Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >"unsubscribe ipfix" in message body >Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 12 15:06:08 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00772 for ; Fri, 12 Apr 2002 15:06:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16w64G-0001vc-00 for ipfix-list@mil.doit.wisc.edu; Fri, 12 Apr 2002 13:46:40 -0500 Received: from mailhub.xacct.com ([204.253.100.25]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16w64D-0001v6-00 for ipfix-arch@net.doit.wisc.edu; Fri, 12 Apr 2002 13:46:37 -0500 Received: (qmail 5128 invoked from network); 12 Apr 2002 18:46:05 -0000 Received: from usmail.xacct.com (204.253.100.12) by mailhub.us.xacct.com with SMTP; 12 Apr 2002 18:46:04 -0000 Received: from Kevinz (pcp820112pcs.nrockv01.md.comcast.net [68.49.52.62]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g3CIkIl15179; Fri, 12 Apr 2002 11:46:18 -0700 Reply-To: From: "kevin.zhang" To: "Benoit Claise" , "Ganesh Sadasivan" Cc: "Robert Lowe" , , "Juergen Quittek" , , Subject: RE: [ipfix-arch] revised terminology Date: Fri, 12 Apr 2002 14:46:26 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3CB6DC69.6020203@cisco.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id PAA00772 Hi All, I was not able to access my email over last week, so I might have missed some of the discussions. My suggestion is to use "control information" as this is quite generic. "control information" is typically bi-directional, but nothing prevents it going only in one-direction, e.g. from exporter to collectors. Thanks, Kevin > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Friday, April 12, 2002 9:09 AM > To: Ganesh Sadasivan; kevin.zhang@xacct.com > Cc: Robert Lowe; calato@riverstonenet.com; Juergen Quittek; > knorseth@enterasys.com; ipfix-arch@net.doit.wisc.edu > Subject: Re: [ipfix-arch] revised terminology > > > All, > > I've been thinking about this term "control stream". I couldn't find a > better term. > I'm proposing that the people who were objecting at the last IETF > meeting propose a better term; I'm remembering of Kevin Zhang (maybe > some others). > Kevin, do you have a better wording? > > Regards, Benoit > > > > >Robert Lowe wrote: > > > >>Ganesh Sadasivan wrote: > >> > >>>>>> Consensus was that both the words "control" and "stream" are > >>>>>> inappropriate. "Data description" was suggested as an > alternative. > >>>>>> > >>>>>"Data description" is not the correct alternative. It covers > only a subset > >>>>>of information that is being referred to. As I mentioned below, this > >>>>>covers other messages like keepalives etc. I can't think of > a better word than > >>>>>"control stream" as of now. Suggest people from the mailing > list to provide > >>>>>a better name. > >>>>> > >>>>Well, how about "operational messaging something-or-other" -- > and I am shooting > >>>>in the dark here. :) What's the something-or-other though? > Not link, and > >>>>if not stream, can it be a flow? > >>>> > >>>I am not satisfied. > >>> > >>I did say I was shooting in the dark! Any other suggestions then? > >> > >>Its purpose is operational, i.e. information passed between > IPFIX devices > >>and IPFIX collectors, so that is just another word for "control". > >> > > > >True it carries operational information - (protocol + meta-data). > > > >> > >>Why was "stream" objectionable? What connotation was deemed > inappropriate? > >>What about "control"? (I wasn't there.) If it was mostly > "stream" that was > >> > > > >I guess people felt that "control" carries only the meta-data which is > >not correct. Why not "stream" - "meta-data" could potentially be > mixed with > >flow records and may not be separable into a stream. But we are talking > >about a conceptual view. > >Still not suggesting any new term... > >Ganesh > > > >>objectionable, then borrow parts of the acronym ICMP that are > appropriate, if > >>not the whole thing. :) Keepalives fit that model anyhow. > >> > >>>> > >>>>>> > >>>>>>I also noted the following... > >>>>>> > >>>>>> Also, the chairs said that explicit references to template-based > >>>>>> application-level protocols need to be removed from the > architecture > >>>>>> document, since the IPFIX requirements do not exclude other > >>>>>> candidate self-describing data encoding methods. > >>>>>> > >>>>>This is being done. So what do you think about the above definition > >>>>>change to template? > >>>>> > >>>>Other than a couple of agreement errors, it seems fine to me. > >>>> > >>>What do you mean by "agreement errors"? > >>> > >>Just English stuff... subject and verb tense (templates is...), > or the use > >>of "information". > >> > >>-Robert > >> > > > > > >-- > >Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >"unsubscribe ipfix" in message body > >Archive http://ipfix.doit.wisc.edu/archive/ > > > > ޖ[hfhzݢ++njwlk/zZyƠyI칻&ޙj:+vw""vvƲ칻&ފ,j܀bm*_ݢ++n܆+ From majordomo@mil.doit.wisc.edu Fri Apr 12 15:24:28 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01350 for ; Fri, 12 Apr 2002 15:24:27 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16w6BN-0001zi-00 for ipfix-list@mil.doit.wisc.edu; Fri, 12 Apr 2002 13:54:01 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.us.nortel.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16w6BL-0001zX-00 for ipfix-data@net.doit.wisc.edu; Fri, 12 Apr 2002 13:53:59 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3CIjBm22971; Fri, 12 Apr 2002 11:45:15 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXM9263>; Fri, 12 Apr 2002 11:45:05 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C01E6B2A7@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: Juergen Quittek , "Norseth, KC" , calato@riverstonenet.com Cc: ipfix-data@net.doit.wisc.edu Subject: RE: [ipfix-data] Data doc - Section 7.11 Date: Fri, 12 Apr 2002 11:45:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E252.2F272618" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E252.2F272618 Content-Type: text/plain; charset="iso-8859-1" Hello Juergen, thanks for the comments. answers inline >-----Original Message----- >From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >Sent: Friday, April 12, 2002 4:30 AM >To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; >calato@riverstonenet.com >Cc: ipfix-data@net.doit.wisc.edu >Subject: Re: [ipfix-data] Data doc - Section 7.11 > > >Hi Reinaldo, > >--On 09 April 2002 14:49 -0700 Reinaldo Penno > wrote: > >> >> In the data doc there was a part that Paul disagrees (or >used to) with me. I'm okay with finding other names anyway, >but IMO the description is better this way >> >> Basically I wanted to change section on NAT/source >virtual/destination virtual to: >> >> 7.11. Middlebox and other Services > >Having to choose between "Virtual Information" and "Middlebox and >other Services", I prefer the first one, because it is as general >as "other services" and it better reflects a meter's view: It does >not care that much about functions and applications/services running >additionally on the same box, it just cares about what such >applications do with packets or beterr with packet headers. Then >the concept of virtual and actual values of header fields seem so >be an adequate and sufficient view of what is happening. no problem, I can change the name. Do you think the description is adequate? >> >> An exporter may be involved in providing services that require >> application level intelligence and/or transform or filter >content such > >I don't think there will be any router or other exporter device >that deserves the attribute 'intelligent'. These boxes are SO dumb! >Just work with them and you'll see :-) he!he! Some of them are a little more 'intelligent'.. > >> as middlebox and OPES respectively. >> >> When the exporter is involved on these types of services the order of >> the IEs that contain information associated with these service MUST >> reflect the order of the operations performed. > >No. We should not have a MUST here. This would mean that you >cannot add middlebox functions to your box without updating the >IPFIX software/hardware. You could not run the same implementation >on boxes with different functionality. It is nice if the IPFIX >device reflects middlebox functions, but a MAY should be >appropriate. What I meant by the above phrase is that the order on which these services are applied are very important ans o should be the reporting. If you apply NAT and then layer 2/3 tunneling is different than the other way around. If the exporter does not indicate this, you might get misleading data in the end. So, my point was if you are ptoviding these service you SHOULD be able to report them on the order they were applied. I think that's reasonable. > >> >> Each type field of the following IEs contain the type of operation >> performed on the packet. The currently available types are: >> >> 1. - NAT >> 2. - LSNAT >> 3. - Twice NAT >> 4. - Request Routing [KRR] >> 5. - Outgoing L3 Tunnel >> 6. - Incoming L3 Tunnel >> 7. - Outgoing L2 Tunnel >> 8. - Incoming L2 Tunnel >> 9. - OPES (several sub-services here) >> 10. - others... >> >> 6.12.1. Modified Source Address >> >> This information element contains the source address of the flow as >> transmitted by the Exporter after a middlebox, OPES or >similar service > >What is a OPES similar service? This is rather unclear, particularly >if you request a MUST to support it. I prefer Paul's term 'redirecting >packets/flows'. > > Juergen > >> was applied to the packet. It may be different than the >source address >> information element, which contains the original source >address of the packet. >> >> The address is defined the same as for Source Address. >> >> Template ID: ### Field Type: ### Size: ### >> >> 6.12.2. Modified Source Port >> >> This information element contains the source port of the flow as >> transmitted by the exporter after a middlebox, OPES or >similar service >> was applied to the packet. It may be different than the source port >> information element, which contains the original source port >of the packet. >> >> Template ID: ### Field Type: ### Size: ### >> >> 6.12.3. Modified Destination Address >> >> This information element contains the destination address of the flow >> as transmitted by the exporter after a middlebox, OPES or similar >> service was applied to the packet. It might be different than the >> destination address information element, which contains the original >> destination address of the packet. >> >> Template ID: ### Field Type: ### Size: ### >> > ------_=_NextPart_001_01C1E252.2F272618 Content-Type: text/html; charset="iso-8859-1" RE: [ipfix-data] Data doc - Section 7.11

Hello Juergen,

thanks for the comments. answers inline

>-----Original Message-----
>From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>Sent: Friday, April 12, 2002 4:30 AM
>To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC;
>calato@riverstonenet.com
>Cc: ipfix-data@net.doit.wisc.edu
>Subject: Re: [ipfix-data] Data doc - Section 7.11
>
>
>Hi Reinaldo,
>
>--On 09 April 2002 14:49 -0700 Reinaldo Penno
><reinaldo_penno@nortelnetworks.com> wrote:
>
>>
>> In the data doc there was a part that Paul disagrees (or
>used to) with me. I'm okay with finding other names anyway,
>but IMO the description is better this way
>>
>> Basically I wanted to change section on NAT/source
>virtual/destination virtual to:
>>
>> 7.11. Middlebox and other Services
>
>Having to choose between "Virtual Information" and "Middlebox and
>other Services", I prefer the first one, because it is as general
>as "other services" and it better reflects a meter's view: It does
>not care that much about functions and applications/services running
>additionally on the same box, it just cares about what such
>applications do with packets or beterr with packet headers. Then
>the concept of virtual and actual values of header fields seem so
>be an adequate and sufficient view of what is happening.

no problem, I can change the name. Do you think the description is adequate?

>>
>> An exporter may be involved in providing services that require
>> application level intelligence and/or transform or filter
>content such
>
>I don't think there will be any router or other exporter device
>that deserves the attribute 'intelligent'. These boxes are SO dumb!
>Just work with them and you'll see :-)

he!he! Some of them are a little more 'intelligent'..

>
>> as middlebox and OPES respectively.
>>
>> When the exporter is involved on these types of services the order of
>> the IEs that contain information associated with these service MUST
>> reflect the order of the operations performed.
>
>No. We should not have a MUST here. This would mean that you
>cannot add middlebox functions to your box without updating the
>IPFIX software/hardware. You could not run the same implementation
>on boxes with different functionality. It is nice if the IPFIX
>device reflects middlebox functions, but a MAY should be
>appropriate.

What I meant by the above phrase is that the order on which these services are applied are very important ans o should be the reporting. If you apply NAT and then layer 2/3 tunneling is different than the other way around. If the exporter does not indicate this, you might get misleading data in the end.

So, my point was if you are ptoviding these service you SHOULD be able to report them on the order they were applied. I think that's reasonable.

>
>>
>> Each type field of the following IEs contain the type of operation
>> performed on the packet. The currently available types are:
>>
>> 1. - NAT
>> 2. - LSNAT
>> 3. - Twice NAT
>> 4. - Request Routing [KRR]
>> 5. - Outgoing L3 Tunnel
>> 6. - Incoming L3 Tunnel
>> 7. - Outgoing L2 Tunnel
>> 8. - Incoming L2 Tunnel
>> 9. - OPES (several sub-services here)
>> 10. - others...
>>
>> 6.12.1.  Modified Source Address
>>
>> This information element contains the source address of the flow as
>> transmitted by the Exporter after a middlebox, OPES or
>similar service
>
>What is a OPES similar service? This is rather unclear, particularly
>if you request a MUST to support it. I prefer Paul's term 'redirecting
>packets/flows'.
>
>    Juergen
>
>> was applied to the packet. It may be different than the
>source address
>> information element, which contains the original source
>address of the packet.
>>
>> The address is defined the same as for Source Address.
>>
>> Template ID: ###   Field Type: ###   Size: ###
>>
>> 6.12.2.  Modified Source Port
>>
>> This information element contains the source port of the flow as
>> transmitted by the exporter after a middlebox, OPES or
>similar service
>> was applied to the packet. It may be different than the source port
>> information element, which contains the original source port
>of the packet.
>>
>> Template ID: ###   Field Type: ###   Size: ###
>>
>> 6.12.3.  Modified Destination Address
>>
>> This information element contains the destination address of the flow
>> as transmitted by the exporter after a middlebox, OPES or similar
>> service was applied to the packet. It might be different than the
>> destination address information element, which contains the original
>> destination address of the packet.
>>
>> Template ID: ###   Field Type: ###   Size: ###
>>
>

------_=_NextPart_001_01C1E252.2F272618-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 12 16:00:29 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02385 for ; Fri, 12 Apr 2002 16:00:28 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16w6yF-000388-00 for ipfix-list@mil.doit.wisc.edu; Fri, 12 Apr 2002 14:44:31 -0500 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16w6yB-00037Y-00 for ipfix-arch@net.doit.wisc.edu; Fri, 12 Apr 2002 14:44:28 -0500 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3CJfh83018413; Fri, 12 Apr 2002 12:41:43 -0700 (PDT) Received: from cisco.com (dhcp-171-71-126-50.cisco.com [171.71.126.50]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABX63761; Fri, 12 Apr 2002 12:42:17 -0700 (PDT) Message-ID: <3CB73876.2A5C9219@cisco.com> Date: Fri, 12 Apr 2002 12:41:43 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: kevin.zhang@xacct.com CC: Benoit Claise , Robert Lowe , calato@riverstonenet.com, Juergen Quittek , knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-2.cisco.com id g3CJfh83018413 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA02385 And for data use "flow data" ? Ganesh "kevin.zhang" wrote: > Hi All, > > I was not able to access my email over last week, so I might have missed some of the discussions. My suggestion is to use "control information" as this is quite generic. "control information" is typically bi-directional, but nothing prevents it going only in one-direction, e.g. from exporter to collectors. > > Thanks, > > Kevin > > > -----Original Message----- > > From: Benoit Claise [mailto:bclaise@cisco.com] > > Sent: Friday, April 12, 2002 9:09 AM > > To: Ganesh Sadasivan; kevin.zhang@xacct.com > > Cc: Robert Lowe; calato@riverstonenet.com; Juergen Quittek; > > knorseth@enterasys.com; ipfix-arch@net.doit.wisc.edu > > Subject: Re: [ipfix-arch] revised terminology > > > > > > All, > > > > I've been thinking about this term "control stream". I couldn't find a > > better term. > > I'm proposing that the people who were objecting at the last IETF > > meeting propose a better term; I'm remembering of Kevin Zhang (maybe > > some others). > > Kevin, do you have a better wording? > > > > Regards, Benoit > > > > > > > >Robert Lowe wrote: > > > > > >>Ganesh Sadasivan wrote: > > >> > > >>>>>> Consensus was that both the words "control" and "stream" are > > >>>>>> inappropriate. "Data description" was suggested as an > > alternative. > > >>>>>> > > >>>>>"Data description" is not the correct alternative. It covers > > only a subset > > >>>>>of information that is being referred to. As I mentioned below, this > > >>>>>covers other messages like keepalives etc. I can't think of > > a better word than > > >>>>>"control stream" as of now. Suggest people from the mailing > > list to provide > > >>>>>a better name. > > >>>>> > > >>>>Well, how about "operational messaging something-or-other" -- > > and I am shooting > > >>>>in the dark here. :) What's the something-or-other though? > > Not link, and > > >>>>if not stream, can it be a flow? > > >>>> > > >>>I am not satisfied. > > >>> > > >>I did say I was shooting in the dark! Any other suggestions then? > > >> > > >>Its purpose is operational, i.e. information passed between > > IPFIX devices > > >>and IPFIX collectors, so that is just another word for "control". > > >> > > > > > >True it carries operational information - (protocol + meta-data). > > > > > >> > > >>Why was "stream" objectionable? What connotation was deemed > > inappropriate? > > >>What about "control"? (I wasn't there.) If it was mostly > > "stream" that was > > >> > > > > > >I guess people felt that "control" carries only the meta-data which is > > >not correct. Why not "stream" - "meta-data" could potentially be > > mixed with > > >flow records and may not be separable into a stream. But we are talking > > >about a conceptual view. > > >Still not suggesting any new term... > > >Ganesh > > > > > >>objectionable, then borrow parts of the acronym ICMP that are > > appropriate, if > > >>not the whole thing. :) Keepalives fit that model anyhow. > > >> > > >>>> > > >>>>>> > > >>>>>>I also noted the following... > > >>>>>> > > >>>>>> Also, the chairs said that explicit references to template-based > > >>>>>> application-level protocols need to be removed from the > > architecture > > >>>>>> document, since the IPFIX requirements do not exclude other > > >>>>>> candidate self-describing data encoding methods. > > >>>>>> > > >>>>>This is being done. So what do you think about the above definition > > >>>>>change to template? > > >>>>> > > >>>>Other than a couple of agreement errors, it seems fine to me. > > >>>> > > >>>What do you mean by "agreement errors"? > > >>> > > >>Just English stuff... subject and verb tense (templates is...), > > or the use > > >>of "information". > > >> > > >>-Robert > > >> > > > > > > > > >-- > > >Help mailto:majordomo@net.doit.wisc.edu and say "help" in > > message body > > >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > >"unsubscribe ipfix" in message body > > >Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > iݢj'zh"ǝݱzZbgnrR{.n+j)mfh޵"qnjwlk+rz*_,j܀bm"qn܆+/=== -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 12 17:06:47 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04265 for ; Fri, 12 Apr 2002 17:06:46 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16w81p-0004Qa-00 for ipfix-list@mil.doit.wisc.edu; Fri, 12 Apr 2002 15:52:17 -0500 Received: from mailhub.xacct.com ([204.253.100.25]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16w81m-0004Q3-00 for ipfix-arch@net.doit.wisc.edu; Fri, 12 Apr 2002 15:52:14 -0500 Received: (qmail 11763 invoked from network); 12 Apr 2002 20:51:42 -0000 Received: from usmail.xacct.com (204.253.100.12) by mailhub.us.xacct.com with SMTP; 12 Apr 2002 20:51:42 -0000 Received: from Kevinz (pcp820112pcs.nrockv01.md.comcast.net [68.49.52.62]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g3CKpul17687; Fri, 12 Apr 2002 13:51:56 -0700 Reply-To: From: "kevin.zhang" To: "Ganesh Sadasivan" Cc: "Benoit Claise" , "Robert Lowe" , , "Juergen Quittek" , , Subject: RE: [ipfix-arch] revised terminology Date: Fri, 12 Apr 2002 16:52:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3CB73876.2A5C9219@cisco.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id RAA04265 IPFIX stands for IP Flow Information eXport. So "flow information" may be a term to consider, though flow data would be fine with me. Thanks, Kevin > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Ganesh Sadasivan > Sent: Friday, April 12, 2002 3:42 PM > To: kevin.zhang@xacct.com > Cc: Benoit Claise; Robert Lowe; calato@riverstonenet.com; Juergen > Quittek; knorseth@enterasys.com; ipfix-arch@net.doit.wisc.edu > Subject: Re: [ipfix-arch] revised terminology > > > And for data use "flow data" ? > Ganesh > > "kevin.zhang" wrote: > > > Hi All, > > > > I was not able to access my email over last week, so I might > have missed some of the discussions. My suggestion is to use > "control information" as this is quite generic. "control > information" is typically bi-directional, but nothing prevents it > going only in one-direction, e.g. from exporter to collectors. > > > > Thanks, > > > > Kevin > > > > > -----Original Message----- > > > From: Benoit Claise [mailto:bclaise@cisco.com] > > > Sent: Friday, April 12, 2002 9:09 AM > > > To: Ganesh Sadasivan; kevin.zhang@xacct.com > > > Cc: Robert Lowe; calato@riverstonenet.com; Juergen Quittek; > > > knorseth@enterasys.com; ipfix-arch@net.doit.wisc.edu > > > Subject: Re: [ipfix-arch] revised terminology > > > > > > > > > All, > > > > > > I've been thinking about this term "control stream". I > couldn't find a > > > better term. > > > I'm proposing that the people who were objecting at the last IETF > > > meeting propose a better term; I'm remembering of Kevin Zhang (maybe > > > some others). > > > Kevin, do you have a better wording? > > > > > > Regards, Benoit > > > > > > > > > > >Robert Lowe wrote: > > > > > > > >>Ganesh Sadasivan wrote: > > > >> > > > >>>>>> Consensus was that both the words "control" and "stream" are > > > >>>>>> inappropriate. "Data description" was suggested as an > > > alternative. > > > >>>>>> > > > >>>>>"Data description" is not the correct alternative. It covers > > > only a subset > > > >>>>>of information that is being referred to. As I mentioned > below, this > > > >>>>>covers other messages like keepalives etc. I can't think of > > > a better word than > > > >>>>>"control stream" as of now. Suggest people from the mailing > > > list to provide > > > >>>>>a better name. > > > >>>>> > > > >>>>Well, how about "operational messaging something-or-other" -- > > > and I am shooting > > > >>>>in the dark here. :) What's the something-or-other though? > > > Not link, and > > > >>>>if not stream, can it be a flow? > > > >>>> > > > >>>I am not satisfied. > > > >>> > > > >>I did say I was shooting in the dark! Any other suggestions then? > > > >> > > > >>Its purpose is operational, i.e. information passed between > > > IPFIX devices > > > >>and IPFIX collectors, so that is just another word for "control". > > > >> > > > > > > > >True it carries operational information - (protocol + meta-data). > > > > > > > >> > > > >>Why was "stream" objectionable? What connotation was deemed > > > inappropriate? > > > >>What about "control"? (I wasn't there.) If it was mostly > > > "stream" that was > > > >> > > > > > > > >I guess people felt that "control" carries only the > meta-data which is > > > >not correct. Why not "stream" - "meta-data" could potentially be > > > mixed with > > > >flow records and may not be separable into a stream. But we > are talking > > > >about a conceptual view. > > > >Still not suggesting any new term... > > > >Ganesh > > > > > > > >>objectionable, then borrow parts of the acronym ICMP that are > > > appropriate, if > > > >>not the whole thing. :) Keepalives fit that model anyhow. > > > >> > > > >>>> > > > >>>>>> > > > >>>>>>I also noted the following... > > > >>>>>> > > > >>>>>> Also, the chairs said that explicit references to > template-based > > > >>>>>> application-level protocols need to be removed from the > > > architecture > > > >>>>>> document, since the IPFIX requirements do not exclude other > > > >>>>>> candidate self-describing data encoding methods. > > > >>>>>> > > > >>>>>This is being done. So what do you think about the above > definition > > > >>>>>change to template? > > > >>>>> > > > >>>>Other than a couple of agreement errors, it seems fine to me. > > > >>>> > > > >>>What do you mean by "agreement errors"? > > > >>> > > > >>Just English stuff... subject and verb tense (templates is...), > > > or the use > > > >>of "information". > > > >> > > > >>-Robert > > > >> > > > > > > > > > > > >-- > > > >Help mailto:majordomo@net.doit.wisc.edu and say "help" in > > > message body > > > >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > >"unsubscribe ipfix" in message body > > > >Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > iݢj'zh"ǝݱzZbgnrR{.n+j)mfh޵" > qnjwlk+rz*_,j܀bm"qn܆+/=== > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ޖ[hfhzݢ++njwlk/zZyƠyI칻&ޙj:+vw""vvƲ칻&ފ,j܀bm*_ݢ++n܆+ From majordomo@mil.doit.wisc.edu Fri Apr 12 21:59:39 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09167 for ; Fri, 12 Apr 2002 21:59:39 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16wCYD-0002ea-00 for ipfix-list@mil.doit.wisc.edu; Fri, 12 Apr 2002 20:42:01 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16wCYB-0002dd-00 for ipfix-data@net.doit.wisc.edu; Fri, 12 Apr 2002 20:41:59 -0500 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g3D1fS884529; Sat, 13 Apr 2002 03:41:28 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA11038; Sat, 13 Apr 2002 03:40:42 +0200 Date: Sat, 13 Apr 2002 03:44:35 +0200 From: Juergen Quittek To: Reinaldo Penno , "Norseth, KC" , calato@riverstonenet.com cc: ipfix-data@net.doit.wisc.edu Subject: RE: [ipfix-data] Data doc - Section 7.11 Message-ID: <21132456.1018669475@[192.168.102.31]> In-Reply-To: <7B802811BE77D51189910002A55CFD2C01E6B2A7@zsc3c032.us.nortel.com> References: <7B802811BE77D51189910002A55CFD2C01E6B2A7@zsc3c032.us.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo, --On 12 April 2002 11:45 -0700 Reinaldo Penno wrote: > > Hello Juergen, > [...] > >>> >>> An exporter may be involved in providing services that require >>> application level intelligence and/or transform or filter >> content such >> >> I don't think there will be any router or other exporter device >> that deserves the attribute 'intelligent'. These boxes are SO dumb! >> Just work with them and you'll see :-) > > he!he! Some of them are a little more 'intelligent'.. If these few lines of code on a middlebox constitute Intelligence, then my Microsoft Word must be a genius ... Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Apr 12 21:59:58 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09181 for ; Fri, 12 Apr 2002 21:59:58 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16wCVS-0002Yx-00 for ipfix-list@mil.doit.wisc.edu; Fri, 12 Apr 2002 20:39:10 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16wCVP-0002YA-00 for ipfix-data@net.doit.wisc.edu; Fri, 12 Apr 2002 20:39:07 -0500 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g3D1ca884492; Sat, 13 Apr 2002 03:38:36 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id DAA11007; Sat, 13 Apr 2002 03:37:48 +0200 Date: Sat, 13 Apr 2002 03:41:40 +0200 From: Juergen Quittek To: Reinaldo Penno , "Norseth, KC" , calato@riverstonenet.com cc: ipfix-data@net.doit.wisc.edu Subject: RE: [ipfix-data] Data doc - Section 7.11 Message-ID: <20956684.1018669299@[192.168.102.31]> In-Reply-To: <7B802811BE77D51189910002A55CFD2C01E6B2A7@zsc3c032.us.nortel.com> References: <7B802811BE77D51189910002A55CFD2C01E6B2A7@zsc3c032.us.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Reinaldo, With 'reflect the order of the operstions performed', do you mean finding out what is the original and what the modified header field? I had a long discussion on the modified scheme versus the modified scheme with Paul: The virtual scheme: Any source-related header field in an arriving packet is called actual. Any destination-reated header field in a leaving packet is called actual. Actual values are the ones usually reported. If the value of a source-related header field in a leaving packet differs from its value in the arriving packet, then this value is called 'virtual'. If the value of a destination-related header field in an arriving packet differs from its value in the leaving packet, then this value is called 'virtual'. The modified scheme: The value of a header field in an arriving packet is called original. Original values are the ones usually reported. If the value of a header field is modified in the leaving packet, then it may be reported as the 'modified' value. In the end we preferred the virtual scheme. But please feel free to convince us that the modified scheme is more appropriate. Juergen --On 12 April 2002 11:45 -0700 Reinaldo Penno wrote: > > Hello Juergen, > > thanks for the comments. answers inline > >> -----Original Message----- >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> Sent: Friday, April 12, 2002 4:30 AM >> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; >> calato@riverstonenet.com >> Cc: ipfix-data@net.doit.wisc.edu >> Subject: Re: [ipfix-data] Data doc - Section 7.11 >> >> >> Hi Reinaldo, >> >> --On 09 April 2002 14:49 -0700 Reinaldo Penno >> wrote: >> >>> >>> In the data doc there was a part that Paul disagrees (or >> used to) with me. I'm okay with finding other names anyway, >> but IMO the description is better this way >>> >>> Basically I wanted to change section on NAT/source >> virtual/destination virtual to: >>> >>> 7.11. Middlebox and other Services >> >> Having to choose between "Virtual Information" and "Middlebox and >> other Services", I prefer the first one, because it is as general >> as "other services" and it better reflects a meter's view: It does >> not care that much about functions and applications/services running >> additionally on the same box, it just cares about what such >> applications do with packets or beterr with packet headers. Then >> the concept of virtual and actual values of header fields seem so >> be an adequate and sufficient view of what is happening. > > no problem, I can change the name. Do you think the description is adequate? > >>> >>> An exporter may be involved in providing services that require >>> application level intelligence and/or transform or filter >> content such >> >> I don't think there will be any router or other exporter device >> that deserves the attribute 'intelligent'. These boxes are SO dumb! >> Just work with them and you'll see :-) > > he!he! Some of them are a little more 'intelligent'.. > >> >>> as middlebox and OPES respectively. >>> >>> When the exporter is involved on these types of services the order of >>> the IEs that contain information associated with these service MUST >>> reflect the order of the operations performed. >> >> No. We should not have a MUST here. This would mean that you >> cannot add middlebox functions to your box without updating the >> IPFIX software/hardware. You could not run the same implementation >> on boxes with different functionality. It is nice if the IPFIX >> device reflects middlebox functions, but a MAY should be >> appropriate. > > What I meant by the above phrase is that the order on which these services are applied are very important ans o should be the reporting. If you apply NAT and then layer 2/3 tunneling is different than the other way around. If the exporter does not > indicate this, you might get misleading data in the end. > > So, my point was if you are ptoviding these service you SHOULD be able to report them on the order they were applied. I think that's reasonable. > >> >>> >>> Each type field of the following IEs contain the type of operation >>> performed on the packet. The currently available types are: >>> >>> 1. - NAT >>> 2. - LSNAT >>> 3. - Twice NAT >>> 4. - Request Routing [KRR] >>> 5. - Outgoing L3 Tunnel >>> 6. - Incoming L3 Tunnel >>> 7. - Outgoing L2 Tunnel >>> 8. - Incoming L2 Tunnel >>> 9. - OPES (several sub-services here) >>> 10. - others... >>> >>> 6.12.1. Modified Source Address >>> >>> This information element contains the source address of the flow as >>> transmitted by the Exporter after a middlebox, OPES or >> similar service >> >> What is a OPES similar service? This is rather unclear, particularly >> if you request a MUST to support it. I prefer Paul's term 'redirecting >> packets/flows'. >> >> Juergen >> >>> was applied to the packet. It may be different than the >> source address >>> information element, which contains the original source >> address of the packet. >>> >>> The address is defined the same as for Source Address. >>> >>> Template ID: ### Field Type: ### Size: ### >>> >>> 6.12.2. Modified Source Port >>> >>> This information element contains the source port of the flow as >>> transmitted by the exporter after a middlebox, OPES or >> similar service >>> was applied to the packet. It may be different than the source port >>> information element, which contains the original source port >> of the packet. >>> >>> Template ID: ### Field Type: ### Size: ### >>> >>> 6.12.3. Modified Destination Address >>> >>> This information element contains the destination address of the flow >>> as transmitted by the exporter after a middlebox, OPES or similar >>> service was applied to the packet. It might be different than the >>> destination address information element, which contains the original >>> destination address of the packet. >>> >>> Template ID: ### Field Type: ### Size: ### >>> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sat Apr 13 02:25:40 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21646 for ; Sat, 13 Apr 2002 02:25:40 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16wGkA-0000LS-00 for ipfix-list@mil.doit.wisc.edu; Sat, 13 Apr 2002 01:10:38 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.us.nortel.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16wGk7-0000Kp-00 for ipfix-data@net.doit.wisc.edu; Sat, 13 Apr 2002 01:10:35 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3D65Dx12600; Fri, 12 Apr 2002 23:05:13 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXM93BY>; Fri, 12 Apr 2002 23:05:07 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C01E6B73D@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: Juergen Quittek , "Norseth, KC" , calato@riverstonenet.com Cc: ipfix-data@net.doit.wisc.edu Subject: RE: [ipfix-data] Data doc - Section 7.11 Date: Fri, 12 Apr 2002 23:05:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E2B1.3234E2A0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E2B1.3234E2A0 Content-Type: text/plain; charset="iso-8859-1" My concern with the "virtual" wording is that there is nothing "virtual" about the modified packet. Virtual implies the original/actual packet is more real than the modified one, which is not. The modified packet can actually be more "real" if you are doing NAT, for instance. My opinion is that another terminology sould be used. As for the first question, imagine you receive a packet and you apply several services to it (NAT, insertion of content, whatever) and you want to report that (the services applied) on flow records. So, the order in which you apply these services matters and so the order in which you report them. As I said, if you apply NAT and then some firewall (possibly dropping the packet), but on the flow records you say the other way around, you will get the wrong picture. This is a easy example, but you can expand that for all other services that modify, drop, tunnel a packet. regards, Reinaldo >-----Original Message----- >From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >Sent: Friday, April 12, 2002 6:42 PM >To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; >calato@riverstonenet.com >Cc: ipfix-data@net.doit.wisc.edu >Subject: RE: [ipfix-data] Data doc - Section 7.11 > > >Hi Reinaldo, > >With 'reflect the order of the operstions performed', do you mean >finding out what is the original and what the modified header field? > >I had a long discussion on the modified scheme versus the modified >scheme with Paul: > >The virtual scheme: > Any source-related header field in an arriving packet is called > actual. Any destination-reated header field in a leaving packet > is called actual. Actual values are the ones usually reported. > > If the value of a source-related header field in a leaving packet > differs from its value in the arriving packet, then this value is > called 'virtual'. If the value of a destination-related header > field in an arriving packet differs from its value in the leaving > packet, then this value is called 'virtual'. > >The modified scheme: > The value of a header field in an arriving packet is called original. > Original values are the ones usually reported. > If the value of a header field is modified in the leaving packet, > then it may be reported as the 'modified' value. > >In the end we preferred the virtual scheme. But please feel free >to convince us that the modified scheme is more appropriate. > > Juergen > > >--On 12 April 2002 11:45 -0700 Reinaldo Penno > wrote: > >> >> Hello Juergen, >> >> thanks for the comments. answers inline >> >>> -----Original Message----- >>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >>> Sent: Friday, April 12, 2002 4:30 AM >>> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; >>> calato@riverstonenet.com >>> Cc: ipfix-data@net.doit.wisc.edu >>> Subject: Re: [ipfix-data] Data doc - Section 7.11 >>> >>> >>> Hi Reinaldo, >>> >>> --On 09 April 2002 14:49 -0700 Reinaldo Penno >>> wrote: >>> >>>> >>>> In the data doc there was a part that Paul disagrees (or >>> used to) with me. I'm okay with finding other names anyway, >>> but IMO the description is better this way >>>> >>>> Basically I wanted to change section on NAT/source >>> virtual/destination virtual to: >>>> >>>> 7.11. Middlebox and other Services >>> >>> Having to choose between "Virtual Information" and "Middlebox and >>> other Services", I prefer the first one, because it is as general >>> as "other services" and it better reflects a meter's view: It does >>> not care that much about functions and applications/services running >>> additionally on the same box, it just cares about what such >>> applications do with packets or beterr with packet headers. Then >>> the concept of virtual and actual values of header fields seem so >>> be an adequate and sufficient view of what is happening. >> >> no problem, I can change the name. Do you think the >description is adequate? >> >>>> >>>> An exporter may be involved in providing services that require >>>> application level intelligence and/or transform or filter >>> content such >>> >>> I don't think there will be any router or other exporter device >>> that deserves the attribute 'intelligent'. These boxes are SO dumb! >>> Just work with them and you'll see :-) >> >> he!he! Some of them are a little more 'intelligent'.. >> >>> >>>> as middlebox and OPES respectively. >>>> >>>> When the exporter is involved on these types of services >the order of >>>> the IEs that contain information associated with these service MUST >>>> reflect the order of the operations performed. >>> >>> No. We should not have a MUST here. This would mean that you >>> cannot add middlebox functions to your box without updating the >>> IPFIX software/hardware. You could not run the same implementation >>> on boxes with different functionality. It is nice if the IPFIX >>> device reflects middlebox functions, but a MAY should be >>> appropriate. >> >> What I meant by the above phrase is that the order on which >these services are applied are very important ans o should be >the reporting. If you apply NAT and then layer 2/3 tunneling >is different than the other way around. If the exporter does not >> indicate this, you might get misleading data in the end. >> >> So, my point was if you are ptoviding these service you >SHOULD be able to report them on the order they were applied. >I think that's reasonable. >> >>> >>>> >>>> Each type field of the following IEs contain the type of operation >>>> performed on the packet. The currently available types are: >>>> >>>> 1. - NAT >>>> 2. - LSNAT >>>> 3. - Twice NAT >>>> 4. - Request Routing [KRR] >>>> 5. - Outgoing L3 Tunnel >>>> 6. - Incoming L3 Tunnel >>>> 7. - Outgoing L2 Tunnel >>>> 8. - Incoming L2 Tunnel >>>> 9. - OPES (several sub-services here) >>>> 10. - others... >>>> >>>> 6.12.1. Modified Source Address >>>> >>>> This information element contains the source address of the flow as >>>> transmitted by the Exporter after a middlebox, OPES or >>> similar service >>> >>> What is a OPES similar service? This is rather unclear, particularly >>> if you request a MUST to support it. I prefer Paul's term >'redirecting >>> packets/flows'. >>> >>> Juergen >>> >>>> was applied to the packet. It may be different than the >>> source address >>>> information element, which contains the original source >>> address of the packet. >>>> >>>> The address is defined the same as for Source Address. >>>> >>>> Template ID: ### Field Type: ### Size: ### >>>> >>>> 6.12.2. Modified Source Port >>>> >>>> This information element contains the source port of the flow as >>>> transmitted by the exporter after a middlebox, OPES or >>> similar service >>>> was applied to the packet. It may be different than the source port >>>> information element, which contains the original source port >>> of the packet. >>>> >>>> Template ID: ### Field Type: ### Size: ### >>>> >>>> 6.12.3. Modified Destination Address >>>> >>>> This information element contains the destination address >of the flow >>>> as transmitted by the exporter after a middlebox, OPES or similar >>>> service was applied to the packet. It might be different than the >>>> destination address information element, which contains >the original >>>> destination address of the packet. >>>> >>>> Template ID: ### Field Type: ### Size: ### >>>> > > > ------_=_NextPart_001_01C1E2B1.3234E2A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-data] Data doc - Section 7.11

My concern with the "virtual" wording is = that there is nothing "virtual" about the modified packet. = Virtual implies the original/actual packet is more real than the = modified one, which is not. The modified packet can actually be more = "real" if you are doing NAT, for instance. My opinion is that = another terminology sould be used.

As for the first question, imagine you receive a = packet and you apply several services to it (NAT, insertion of content, = whatever) and you want to report that (the services applied) on flow = records.

So, the order in which you apply these services = matters and so the order in which you report them. As I said, if you = apply NAT and then some firewall (possibly dropping the packet), but on = the flow records you say the other way around, you will get the wrong = picture. This is a easy example, but you can expand that for all other = services that modify, drop, tunnel a packet.

regards,

Reinaldo

>-----Original Message-----
>From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>Sent: Friday, April 12, 2002 6:42 PM
>To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, = KC;
>calato@riverstonenet.com
>Cc: ipfix-data@net.doit.wisc.edu
>Subject: RE: [ipfix-data] Data doc - Section = 7.11
>
>
>Hi Reinaldo,
>
>With 'reflect the order of the operstions = performed', do you mean
>finding out what is the original and what the = modified header field?
>
>I had a long discussion on the modified scheme = versus the modified
>scheme with Paul:
>
>The virtual scheme:
>  Any source-related header field in an = arriving packet is called
>  actual. Any destination-reated header = field in a leaving packet
>  is called actual. Actual values are the = ones usually reported.
>
>  If the value of a source-related header = field in a leaving packet
>  differs from its value in the arriving = packet, then this value is
>  called 'virtual'. If the value of a = destination-related header
>  field in an arriving packet differs from = its value in the leaving
>  packet, then this value is called = 'virtual'.
>
>The modified scheme:
>  The value of a header field in an = arriving packet is called original.
>  Original values are the ones usually = reported.
>  If the value of a header field is = modified in the leaving packet,
>  then it may be reported as the 'modified' = value.
>
>In the end we preferred the virtual scheme. But = please feel free
>to convince us that the modified scheme is more = appropriate.
>
>    Juergen
>
>
>--On 12 April 2002 11:45 -0700 Reinaldo Penno =
><reinaldo_penno@nortelnetworks.com> = wrote:
>
>>
>> Hello Juergen,
>>
>> thanks for the comments. answers = inline
>>
>>> -----Original Message-----
>>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>>> Sent: Friday, April 12, 2002 4:30 = AM
>>> To: Penno, Reinaldo [SC9:T327:EXCH]; = Norseth, KC;
>>> calato@riverstonenet.com
>>> Cc: ipfix-data@net.doit.wisc.edu
>>> Subject: Re: [ipfix-data] Data doc - = Section 7.11
>>>
>>>
>>> Hi Reinaldo,
>>>
>>> --On 09 April 2002 14:49 -0700 Reinaldo = Penno
>>> = <reinaldo_penno@nortelnetworks.com> wrote:
>>>
>>>>
>>>> In the data doc there was a part = that Paul disagrees (or
>>> used to) with me. I'm okay with finding = other names anyway,
>>> but IMO the description is better this = way
>>>>
>>>> Basically I wanted to change = section on NAT/source
>>> virtual/destination virtual to:
>>>>
>>>> 7.11. Middlebox and other = Services
>>>
>>> Having to choose between "Virtual = Information" and "Middlebox and
>>> other Services", I prefer the = first one, because it is as general
>>> as "other services" and it = better reflects a meter's view: It does
>>> not care that much about functions and = applications/services running
>>> additionally on the same box, it just = cares about what such
>>> applications do with packets or beterr = with packet headers. Then
>>> the concept of virtual and actual = values of header fields seem so
>>> be an adequate and sufficient view of = what is happening.
>>
>> no problem, I can change the name. Do you = think the
>description is adequate?
>>
>>>>
>>>> An exporter may be involved in = providing services that require
>>>> application level intelligence = and/or transform or filter
>>> content such
>>>
>>> I don't think there will be any router = or other exporter device
>>> that deserves the attribute = 'intelligent'. These boxes are SO dumb!
>>> Just work with them and you'll see = :-)
>>
>> he!he! Some of them are a little more = 'intelligent'..
>>
>>>
>>>> as middlebox and OPES = respectively.
>>>>
>>>> When the exporter is involved on = these types of services
>the order of
>>>> the IEs that contain information = associated with these service MUST
>>>> reflect the order of the operations = performed.
>>>
>>> No. We should not have a MUST here. = This would mean that you
>>> cannot add middlebox functions to your = box without updating the
>>> IPFIX software/hardware. You could not = run the same implementation
>>> on boxes with different functionality. = It is nice if the IPFIX
>>> device reflects middlebox functions, = but a MAY should be
>>> appropriate.
>>
>> What I meant by the above phrase is that = the order on which
>these services are applied are very important = ans o should be
>the reporting. If you apply NAT and then layer = 2/3 tunneling
>is different than the other way around. If the = exporter does not
>> indicate this, you might get misleading = data in the end.
>>
>> So, my point was if you are ptoviding these = service you
>SHOULD be able to report them on the order they = were applied.
>I think that's reasonable.
>>
>>>
>>>>
>>>> Each type field of the following = IEs contain the type of operation
>>>> performed on the packet. The = currently available types are:
>>>>
>>>> 1. - NAT
>>>> 2. - LSNAT
>>>> 3. - Twice NAT
>>>> 4. - Request Routing [KRR]
>>>> 5. - Outgoing L3 Tunnel
>>>> 6. - Incoming L3 Tunnel
>>>> 7. - Outgoing L2 Tunnel
>>>> 8. - Incoming L2 Tunnel
>>>> 9. - OPES (several sub-services = here)
>>>> 10. - others...
>>>>
>>>> 6.12.1.  Modified Source = Address
>>>>
>>>> This information element contains = the source address of the flow as
>>>> transmitted by the Exporter after a = middlebox, OPES or
>>> similar service
>>>
>>> What is a OPES similar service? This is = rather unclear, particularly
>>> if you request a MUST to support it. I = prefer Paul's term
>'redirecting
>>> packets/flows'.
>>>
>>>    Juergen
>>>
>>>> was applied to the packet. It may = be different than the
>>> source address
>>>> information element, which contains = the original source
>>> address of the packet.
>>>>
>>>> The address is defined the same as = for Source Address.
>>>>
>>>> Template ID: ###   Field = Type: ###   Size: ###
>>>>
>>>> 6.12.2.  Modified Source = Port
>>>>
>>>> This information element contains = the source port of the flow as
>>>> transmitted by the exporter after a = middlebox, OPES or
>>> similar service
>>>> was applied to the packet. It may = be different than the source port
>>>> information element, which contains = the original source port
>>> of the packet.
>>>>
>>>> Template ID: ###   Field = Type: ###   Size: ###
>>>>
>>>> 6.12.3.  Modified Destination = Address
>>>>
>>>> This information element contains = the destination address
>of the flow
>>>> as transmitted by the exporter = after a middlebox, OPES or similar
>>>> service was applied to the packet. = It might be different than the
>>>> destination address information = element, which contains
>the original
>>>> destination address of the = packet.
>>>>
>>>> Template ID: ###   Field = Type: ###   Size: ###
>>>>
>
>
>

------_=_NextPart_001_01C1E2B1.3234E2A0-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sat Apr 13 22:28:54 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03101 for ; Sat, 13 Apr 2002 22:28:54 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16wZQJ-0002qo-00 for ipfix-list@mil.doit.wisc.edu; Sat, 13 Apr 2002 21:07:23 -0500 Received: from fe4.rdc-kc.rr.com ([24.94.163.51] helo=mail4.new.rr.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16wZQF-0002qg-00 for ipfix-arch@net.doit.wisc.edu; Sat, 13 Apr 2002 21:07:19 -0500 Received: from lawrence.edu ([24.208.9.15]) by mail4.new.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Sat, 13 Apr 2002 21:05:12 -0500 Message-ID: <3CB8E444.C995006E@lawrence.edu> Date: Sat, 13 Apr 2002 21:07:00 -0500 From: Robert Lowe X-Mailer: Mozilla 4.7 [en]C-CCK-MCD EBM-Compaq1 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: kevin.zhang@xacct.com CC: Ganesh Sadasivan , Benoit Claise , calato@riverstonenet.com, Juergen Quittek , knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit "kevin.zhang" wrote: > > IPFIX stands for IP Flow Information eXport. So "flow information" may be a term to consider, though flow data would be fine with me. I would encourage uniformity in approach, i.e. categorize them both the same. That said, I think I still favor message rather than information, since it more strongly implies movement or transfer between exporter and collector. -Robert > > > -----Original Message----- > > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > > Of Ganesh Sadasivan > > Sent: Friday, April 12, 2002 3:42 PM > > To: kevin.zhang@xacct.com > > Cc: Benoit Claise; Robert Lowe; calato@riverstonenet.com; Juergen > > Quittek; knorseth@enterasys.com; ipfix-arch@net.doit.wisc.edu > > Subject: Re: [ipfix-arch] revised terminology > > > > > > And for data use "flow data" ? > > Ganesh > > > > "kevin.zhang" wrote: > > > > > Hi All, > > > > > > I was not able to access my email over last week, so I might > > have missed some of the discussions. My suggestion is to use > > "control information" as this is quite generic. "control > > information" is typically bi-directional, but nothing prevents it > > going only in one-direction, e.g. from exporter to collectors. > > > > > > Thanks, > > > > > > Kevin > > > > > > > -----Original Message----- > > > > From: Benoit Claise [mailto:bclaise@cisco.com] > > > > Sent: Friday, April 12, 2002 9:09 AM > > > > To: Ganesh Sadasivan; kevin.zhang@xacct.com > > > > Cc: Robert Lowe; calato@riverstonenet.com; Juergen Quittek; > > > > knorseth@enterasys.com; ipfix-arch@net.doit.wisc.edu > > > > Subject: Re: [ipfix-arch] revised terminology > > > > > > > > > > > > All, > > > > > > > > I've been thinking about this term "control stream". I > > couldn't find a > > > > better term. > > > > I'm proposing that the people who were objecting at the last IETF > > > > meeting propose a better term; I'm remembering of Kevin Zhang (maybe > > > > some others). > > > > Kevin, do you have a better wording? > > > > > > > > Regards, Benoit > > > > > > > > > > > > > >Robert Lowe wrote: > > > > > > > > > >>Ganesh Sadasivan wrote: > > > > >> > > > > >>>>>> Consensus was that both the words "control" and "stream" are > > > > >>>>>> inappropriate. "Data description" was suggested as an > > > > alternative. > > > > >>>>>> > > > > >>>>>"Data description" is not the correct alternative. It covers > > > > only a subset > > > > >>>>>of information that is being referred to. As I mentioned > > below, this > > > > >>>>>covers other messages like keepalives etc. I can't think of > > > > a better word than > > > > >>>>>"control stream" as of now. Suggest people from the mailing > > > > list to provide > > > > >>>>>a better name. > > > > >>>>> > > > > >>>>Well, how about "operational messaging something-or-other" -- > > > > and I am shooting > > > > >>>>in the dark here. :) What's the something-or-other though? > > > > Not link, and > > > > >>>>if not stream, can it be a flow? > > > > >>>> > > > > >>>I am not satisfied. > > > > >>> > > > > >>I did say I was shooting in the dark! Any other suggestions then? > > > > >> > > > > >>Its purpose is operational, i.e. information passed between > > > > IPFIX devices > > > > >>and IPFIX collectors, so that is just another word for "control". > > > > >> > > > > > > > > > >True it carries operational information - (protocol + meta-data). > > > > > > > > > >> > > > > >>Why was "stream" objectionable? What connotation was deemed > > > > inappropriate? > > > > >>What about "control"? (I wasn't there.) If it was mostly > > > > "stream" that was > > > > >> > > > > > > > > > >I guess people felt that "control" carries only the > > meta-data which is > > > > >not correct. Why not "stream" - "meta-data" could potentially be > > > > mixed with > > > > >flow records and may not be separable into a stream. But we > > are talking > > > > >about a conceptual view. > > > > >Still not suggesting any new term... > > > > >Ganesh > > > > > > > > > >>objectionable, then borrow parts of the acronym ICMP that are > > > > appropriate, if > > > > >>not the whole thing. :) Keepalives fit that model anyhow. > > > > >> > > > > >>>> > > > > >>>>>> > > > > >>>>>>I also noted the following... > > > > >>>>>> > > > > >>>>>> Also, the chairs said that explicit references to > > template-based > > > > >>>>>> application-level protocols need to be removed from the > > > > architecture > > > > >>>>>> document, since the IPFIX requirements do not exclude other > > > > >>>>>> candidate self-describing data encoding methods. > > > > >>>>>> > > > > >>>>>This is being done. So what do you think about the above > > definition > > > > >>>>>change to template? > > > > >>>>> > > > > >>>>Other than a couple of agreement errors, it seems fine to me. > > > > >>>> > > > > >>>What do you mean by "agreement errors"? > > > > >>> > > > > >>Just English stuff... subject and verb tense (templates is...), > > > > or the use > > > > >>of "information". > > > > >> > > > > >>-Robert > > > > >> > > > > > > > > > > > > > > >-- > > > > >Help mailto:majordomo@net.doit.wisc.edu and say "help" in > > > > message body > > > > >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > > >"unsubscribe ipfix" in message body > > > > >Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > > > > > iݢj'zh"ǝݱzZbgnrR{.n+j)mfh޵" > > qnjwlk+rz*_,j܀bm"qn܆+/=== > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > > message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/iݢj'zh"ǝݱzZbgnrR{.n+j)mfh޵"qnjwlk+rz*_,j܀bm"qn܆+/=== -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Apr 15 10:50:58 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19585 for ; Mon, 15 Apr 2002 10:50:58 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16x7YN-0004o1-00 for ipfix-list@mil.doit.wisc.edu; Mon, 15 Apr 2002 09:33:59 -0500 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16x7YL-0004nj-00 for ipfix-arch@net.doit.wisc.edu; Mon, 15 Apr 2002 09:33:57 -0500 Received: from riverstonenet.com (134.141.180.90 [134.141.180.90]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H23R9YQ8; Mon, 15 Apr 2002 07:32:19 -0700 Message-ID: <3CBAE474.EE9BCA98@riverstonenet.com> Date: Mon, 15 Apr 2002 10:32:20 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan CC: Juergen Quittek , ipfix-arch@net.doit.wisc.edu Subject: Re: observation point limits (was: Re: [ipfix-arch] revised terminology) References: <3CAB9C2A.7226EF33@cisco.com> <3095961.1017913338@[192.168.102.164]> <3CAE2DFA.26B1ECD9@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh Sadasivan wrote: > > Hi Jurgene, > Here are my thougts. > > Juergen Quittek wrote: > > > Ganesh, > > > > Yes, that's the point: > > > > What - or where - is the IPFIX boundary? > > Is the maximum level of aggregation a single device? > > Yes. I mean an observation domain should not span multiple > network devices. Atleast I do not know of a concerete example > as to why it should be otherwise. > > > > > > > What is the largest observation point? > > The largest aggregatable interface defined by the network > device. This may be a single interface, a set of interfaces or a > logical interface as far as the network device is concerned. > I do not disagree with Paul's idea of heirarchical observation > points. But can't this be done outside the IPFIX device. > Sorry this response it late. But why do we need to limit an IPFIX device to only those devices that process packets directly? Why can't an IPFIX device be a device that processes certain kinds of information? For example, IP header info, etc... Then our architecture can be multi-layered. I believe that a multi-layered approach would be a more scalable solution. Which, when it comes to network accounting, is critical. I must admit I haven't followed closely all the discussions on the architecture, so smack me down if this was already covered, but I don't recall seeing it discussed. > > > > Or: What is the largest set of observation points out of > > which observed packets may be aggregated into a single flow? > > The set of all observation points within an observation domain. > > > > > > > - single interface of a single device > > - set of interfaces of a single device > > - all interfaces of a device > > Yes cut below. > > > > > ----------------- cut? ------------------ > > - several devices > > - entire network > > Thanks > Ganesh -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Apr 15 11:48:10 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20811 for ; Mon, 15 Apr 2002 11:48:10 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16x8Mr-0005sZ-00 for ipfix-list@mil.doit.wisc.edu; Mon, 15 Apr 2002 10:26:09 -0500 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16x8Mo-0005rs-00 for ipfix-arch@net.doit.wisc.edu; Mon, 15 Apr 2002 10:26:06 -0500 Received: from riverstonenet.com (134.141.180.90 [134.141.180.90]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H23R9Y93; Mon, 15 Apr 2002 08:24:29 -0700 Message-ID: <3CBAF0AD.303E4E91@riverstonenet.com> Date: Mon, 15 Apr 2002 11:24:29 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: Ganesh Sadasivan , kevin.zhang@xacct.com, Robert Lowe , Juergen Quittek , knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] revised terminology References: <12205450.1017371280@[192.168.102.31]> <3CADB5BA.F3E7D73D@riverstonenet.com> <3CAE2485.63C9AAD@cisco.com> <3CAE2DB3.3BE698DB@lawrence.edu> <3CAE30EF.5C93E889@cisco.com> <3CAE3593.2C598269@lawrence.edu> <3CB2914A.C1A084AE@cisco.com> <3CB36E9F.2227C7B5@lawrence.edu> <3CB38672.DF672C2C@cisco.com> <3CB6DC69.6020203@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit From what I recall, the issue was that KC used the term "control stream" with the meaning of "data description". Hence the suggestion that he replace those words in his presentation. Seems to me "control stream" should be OK in the arch doc. The other one mentioned by Robert Lowe is pretty good too, that being "operational Stream". Paul Benoit Claise wrote: > > All, > > I've been thinking about this term "control stream". I couldn't find a > better term. > I'm proposing that the people who were objecting at the last IETF > meeting propose a better term; I'm remembering of Kevin Zhang (maybe > some others). > Kevin, do you have a better wording? > > Regards, Benoit > > > > >Robert Lowe wrote: > > > >>Ganesh Sadasivan wrote: > >> > >>>>>> Consensus was that both the words "control" and "stream" are > >>>>>> inappropriate. "Data description" was suggested as an alternative. > >>>>>> > >>>>>"Data description" is not the correct alternative. It covers only a subset > >>>>>of information that is being referred to. As I mentioned below, this > >>>>>covers other messages like keepalives etc. I can't think of a better word than > >>>>>"control stream" as of now. Suggest people from the mailing list to provide > >>>>>a better name. > >>>>> > >>>>Well, how about "operational messaging something-or-other" -- and I am shooting > >>>>in the dark here. :) What's the something-or-other though? Not link, and > >>>>if not stream, can it be a flow? > >>>> > >>>I am not satisfied. > >>> > >>I did say I was shooting in the dark! Any other suggestions then? > >> > >>Its purpose is operational, i.e. information passed between IPFIX devices > >>and IPFIX collectors, so that is just another word for "control". > >> > > > >True it carries operational information - (protocol + meta-data). > > > >> > >>Why was "stream" objectionable? What connotation was deemed inappropriate? > >>What about "control"? (I wasn't there.) If it was mostly "stream" that was > >> > > > >I guess people felt that "control" carries only the meta-data which is > >not correct. Why not "stream" - "meta-data" could potentially be mixed with > >flow records and may not be separable into a stream. But we are talking > >about a conceptual view. > >Still not suggesting any new term... > >Ganesh > > > >>objectionable, then borrow parts of the acronym ICMP that are appropriate, if > >>not the whole thing. :) Keepalives fit that model anyhow. > >> > >>>> > >>>>>> > >>>>>>I also noted the following... > >>>>>> > >>>>>> Also, the chairs said that explicit references to template-based > >>>>>> application-level protocols need to be removed from the architecture > >>>>>> document, since the IPFIX requirements do not exclude other > >>>>>> candidate self-describing data encoding methods. > >>>>>> > >>>>>This is being done. So what do you think about the above definition > >>>>>change to template? > >>>>> > >>>>Other than a couple of agreement errors, it seems fine to me. > >>>> > >>>What do you mean by "agreement errors"? > >>> > >>Just English stuff... subject and verb tense (templates is...), or the use > >>of "information". > >> > >>-Robert > >> > > > > > >-- > >Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >"unsubscribe ipfix" in message body > >Archive http://ipfix.doit.wisc.edu/archive/ > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Apr 15 12:00:18 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21505 for ; Mon, 15 Apr 2002 12:00:18 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16x8cr-0006GP-00 for ipfix-list@mil.doit.wisc.edu; Mon, 15 Apr 2002 10:42:41 -0500 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16x8cq-0006Fj-00 for ipfix-data@net.doit.wisc.edu; Mon, 15 Apr 2002 10:42:40 -0500 Received: from riverstonenet.com (134.141.180.90 [134.141.180.90]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H23R9ZDN; Mon, 15 Apr 2002 08:41:00 -0700 Message-ID: <3CBAF48C.661BD6FD@riverstonenet.com> Date: Mon, 15 Apr 2002 11:41:00 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: Juergen Quittek , "Norseth, KC" , ipfix-data@net.doit.wisc.edu Subject: Re: [ipfix-data] Data doc - Section 7.11 References: <7B802811BE77D51189910002A55CFD2C01E6B73D@zsc3c032.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo Penno wrote: > > My concern with the "virtual" wording is that there is nothing > "virtual" about the modified packet. Virtual implies the > original/actual packet is more real than the modified one, which is > not. The modified packet can actually be more "real" if you are doing > NAT, for instance. My opinion is that another terminology sould be > used. > > As for the first question, imagine you receive a packet and you apply > several services to it (NAT, insertion of content, whatever) and you > want to report that (the services applied) on flow records. > > So, the order in which you apply these services matters and so the > order in which you report them. As I said, if you apply NAT and then > some firewall (possibly dropping the packet), but on the flow records > you say the other way around, you will get the wrong picture. This is > a easy example, but you can expand that for all other services that > modify, drop, tunnel a packet. If you are saying that if more than one of these fields are reported in a flow then they must be in order,that seems reasonable to me too. But we are NOT saying you must report the fields in the first place, correct? > > regards, > > Reinaldo > > >-----Original Message----- > >From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > >Sent: Friday, April 12, 2002 6:42 PM > >To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; > >calato@riverstonenet.com > >Cc: ipfix-data@net.doit.wisc.edu > >Subject: RE: [ipfix-data] Data doc - Section 7.11 > > > > > >Hi Reinaldo, > > > >With 'reflect the order of the operstions performed', do you mean > >finding out what is the original and what the modified header field? > > > >I had a long discussion on the modified scheme versus the modified > >scheme with Paul: > > > >The virtual scheme: > > Any source-related header field in an arriving packet is called > > actual. Any destination-reated header field in a leaving packet > > is called actual. Actual values are the ones usually reported. > > > > If the value of a source-related header field in a leaving packet > > differs from its value in the arriving packet, then this value is > > called 'virtual'. If the value of a destination-related header > > field in an arriving packet differs from its value in the leaving > > packet, then this value is called 'virtual'. > > > >The modified scheme: > > The value of a header field in an arriving packet is called > original. > > Original values are the ones usually reported. > > If the value of a header field is modified in the leaving packet, > > then it may be reported as the 'modified' value. > > > >In the end we preferred the virtual scheme. But please feel free > >to convince us that the modified scheme is more appropriate. > > > > Juergen > > > > > >--On 12 April 2002 11:45 -0700 Reinaldo Penno > > wrote: > > > >> > >> Hello Juergen, > >> > >> thanks for the comments. answers inline > >> > >>> -----Original Message----- > >>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > >>> Sent: Friday, April 12, 2002 4:30 AM > >>> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; > >>> calato@riverstonenet.com > >>> Cc: ipfix-data@net.doit.wisc.edu > >>> Subject: Re: [ipfix-data] Data doc - Section 7.11 > >>> > >>> > >>> Hi Reinaldo, > >>> > >>> --On 09 April 2002 14:49 -0700 Reinaldo Penno > >>> wrote: > >>> > >>>> > >>>> In the data doc there was a part that Paul disagrees (or > >>> used to) with me. I'm okay with finding other names anyway, > >>> but IMO the description is better this way > >>>> > >>>> Basically I wanted to change section on NAT/source > >>> virtual/destination virtual to: > >>>> > >>>> 7.11. Middlebox and other Services > >>> > >>> Having to choose between "Virtual Information" and "Middlebox and > >>> other Services", I prefer the first one, because it is as general > >>> as "other services" and it better reflects a meter's view: It does > > >>> not care that much about functions and applications/services > running > >>> additionally on the same box, it just cares about what such > >>> applications do with packets or beterr with packet headers. Then > >>> the concept of virtual and actual values of header fields seem so > >>> be an adequate and sufficient view of what is happening. > >> > >> no problem, I can change the name. Do you think the > >description is adequate? > >> > >>>> > >>>> An exporter may be involved in providing services that require > >>>> application level intelligence and/or transform or filter > >>> content such > >>> > >>> I don't think there will be any router or other exporter device > >>> that deserves the attribute 'intelligent'. These boxes are SO > dumb! > >>> Just work with them and you'll see :-) > >> > >> he!he! Some of them are a little more 'intelligent'.. > >> > >>> > >>>> as middlebox and OPES respectively. > >>>> > >>>> When the exporter is involved on these types of services > >the order of > >>>> the IEs that contain information associated with these service > MUST > >>>> reflect the order of the operations performed. > >>> > >>> No. We should not have a MUST here. This would mean that you > >>> cannot add middlebox functions to your box without updating the > >>> IPFIX software/hardware. You could not run the same implementation > > >>> on boxes with different functionality. It is nice if the IPFIX > >>> device reflects middlebox functions, but a MAY should be > >>> appropriate. > >> > >> What I meant by the above phrase is that the order on which > >these services are applied are very important ans o should be > >the reporting. If you apply NAT and then layer 2/3 tunneling > >is different than the other way around. If the exporter does not > >> indicate this, you might get misleading data in the end. > >> > >> So, my point was if you are ptoviding these service you > >SHOULD be able to report them on the order they were applied. > >I think that's reasonable. > >> > >>> > >>>> > >>>> Each type field of the following IEs contain the type of > operation > >>>> performed on the packet. The currently available types are: > >>>> > >>>> 1. - NAT > >>>> 2. - LSNAT > >>>> 3. - Twice NAT > >>>> 4. - Request Routing [KRR] > >>>> 5. - Outgoing L3 Tunnel > >>>> 6. - Incoming L3 Tunnel > >>>> 7. - Outgoing L2 Tunnel > >>>> 8. - Incoming L2 Tunnel > >>>> 9. - OPES (several sub-services here) > >>>> 10. - others... > >>>> > >>>> 6.12.1. Modified Source Address > >>>> > >>>> This information element contains the source address of the flow > as > >>>> transmitted by the Exporter after a middlebox, OPES or > >>> similar service > >>> > >>> What is a OPES similar service? This is rather unclear, > particularly > >>> if you request a MUST to support it. I prefer Paul's term > >'redirecting > >>> packets/flows'. > >>> > >>> Juergen > >>> > >>>> was applied to the packet. It may be different than the > >>> source address > >>>> information element, which contains the original source > >>> address of the packet. > >>>> > >>>> The address is defined the same as for Source Address. > >>>> > >>>> Template ID: ### Field Type: ### Size: ### > >>>> > >>>> 6.12.2. Modified Source Port > >>>> > >>>> This information element contains the source port of the flow as > >>>> transmitted by the exporter after a middlebox, OPES or > >>> similar service > >>>> was applied to the packet. It may be different than the source > port > >>>> information element, which contains the original source port > >>> of the packet. > >>>> > >>>> Template ID: ### Field Type: ### Size: ### > >>>> > >>>> 6.12.3. Modified Destination Address > >>>> > >>>> This information element contains the destination address > >of the flow > >>>> as transmitted by the exporter after a middlebox, OPES or similar > > >>>> service was applied to the packet. It might be different than the > > >>>> destination address information element, which contains > >the original > >>>> destination address of the packet. > >>>> > >>>> Template ID: ### Field Type: ### Size: ### > >>>> > > > > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Apr 15 13:06:18 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27978 for ; Mon, 15 Apr 2002 13:06:18 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16x9iN-00000O-00 for ipfix-list@mil.doit.wisc.edu; Mon, 15 Apr 2002 11:52:27 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16x9iJ-0007mr-00 for ipfix-data@net.doit.wisc.edu; Mon, 15 Apr 2002 11:52:23 -0500 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g3FGpq870031; Mon, 15 Apr 2002 18:51:52 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA08232; Mon, 15 Apr 2002 18:50:57 +0200 Date: Mon, 15 Apr 2002 18:55:06 +0200 From: Juergen Quittek To: Reinaldo Penno , "Norseth, KC" , calato@riverstonenet.com cc: ipfix-data@net.doit.wisc.edu Subject: RE: [ipfix-data] Data doc - Section 7.11 Message-ID: <3369665.1018896906@[192.168.102.164]> In-Reply-To: <7B802811BE77D51189910002A55CFD2C01E6B73D@zsc3c032.us.nortel.com> References: <7B802811BE77D51189910002A55CFD2C01E6B73D@zsc3c032.us.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo, --On 12 April 2002 23:05 -0700 Reinaldo Penno wrote: > > My concern with the "virtual" wording is that there is nothing > "virtual" about the modified packet. Virtual implies the > original/actual packet is more real than the modified one, Not the packet is virtual, but the header entry for source or destination addresses may be virtual. If a NAT replaces the source address by its own one while forwarding a packet, then I think it is acceptable calling the modified source address field in the leaving packet 'virtual'. Juergen > which is not. The modified packet can actually be more "real" > if you are > doing NAT, for instance. My opinion is that another terminology sould be used. > > As for the first question, imagine you receive a packet and you apply several services to it (NAT, insertion of content, whatever) and you want to report that (the services applied) on flow records. > > So, the order in which you apply these services matters and so the order in which you report them. As I said, if you apply NAT and then some firewall (possibly dropping the packet), but on the flow records you say the other way around, you will get the > wrong picture. This is a easy example, but you can expand that for all other services that modify, drop, tunnel a packet. > > regards, > > Reinaldo > >> -----Original Message----- >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> Sent: Friday, April 12, 2002 6:42 PM >> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; >> calato@riverstonenet.com >> Cc: ipfix-data@net.doit.wisc.edu >> Subject: RE: [ipfix-data] Data doc - Section 7.11 >> >> >> Hi Reinaldo, >> >> With 'reflect the order of the operstions performed', do you mean >> finding out what is the original and what the modified header field? >> >> I had a long discussion on the modified scheme versus the modified >> scheme with Paul: >> >> The virtual scheme: >> Any source-related header field in an arriving packet is called >> actual. Any destination-reated header field in a leaving packet >> is called actual. Actual values are the ones usually reported. >> >> If the value of a source-related header field in a leaving packet >> differs from its value in the arriving packet, then this value is >> called 'virtual'. If the value of a destination-related header >> field in an arriving packet differs from its value in the leaving >> packet, then this value is called 'virtual'. >> >> The modified scheme: >> The value of a header field in an arriving packet is called original. >> Original values are the ones usually reported. >> If the value of a header field is modified in the leaving packet, >> then it may be reported as the 'modified' value. >> >> In the end we preferred the virtual scheme. But please feel free >> to convince us that the modified scheme is more appropriate. >> >> Juergen >> >> >> --On 12 April 2002 11:45 -0700 Reinaldo Penno >> wrote: >> >>> >>> Hello Juergen, >>> >>> thanks for the comments. answers inline >>> >>>> -----Original Message----- >>>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >>>> Sent: Friday, April 12, 2002 4:30 AM >>>> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; >>>> calato@riverstonenet.com >>>> Cc: ipfix-data@net.doit.wisc.edu >>>> Subject: Re: [ipfix-data] Data doc - Section 7.11 >>>> >>>> >>>> Hi Reinaldo, >>>> >>>> --On 09 April 2002 14:49 -0700 Reinaldo Penno >>>> wrote: >>>> >>>>> >>>>> In the data doc there was a part that Paul disagrees (or >>>> used to) with me. I'm okay with finding other names anyway, >>>> but IMO the description is better this way >>>>> >>>>> Basically I wanted to change section on NAT/source >>>> virtual/destination virtual to: >>>>> >>>>> 7.11. Middlebox and other Services >>>> >>>> Having to choose between "Virtual Information" and "Middlebox and >>>> other Services", I prefer the first one, because it is as general >>>> as "other services" and it better reflects a meter's view: It does >>>> not care that much about functions and applications/services running >>>> additionally on the same box, it just cares about what such >>>> applications do with packets or beterr with packet headers. Then >>>> the concept of virtual and actual values of header fields seem so >>>> be an adequate and sufficient view of what is happening. >>> >>> no problem, I can change the name. Do you think the >> description is adequate? >>> >>>>> >>>>> An exporter may be involved in providing services that require >>>>> application level intelligence and/or transform or filter >>>> content such >>>> >>>> I don't think there will be any router or other exporter device >>>> that deserves the attribute 'intelligent'. These boxes are SO dumb! >>>> Just work with them and you'll see :-) >>> >>> he!he! Some of them are a little more 'intelligent'.. >>> >>>> >>>>> as middlebox and OPES respectively. >>>>> >>>>> When the exporter is involved on these types of services >> the order of >>>>> the IEs that contain information associated with these service MUST >>>>> reflect the order of the operations performed. >>>> >>>> No. We should not have a MUST here. This would mean that you >>>> cannot add middlebox functions to your box without updating the >>>> IPFIX software/hardware. You could not run the same implementation >>>> on boxes with different functionality. It is nice if the IPFIX >>>> device reflects middlebox functions, but a MAY should be >>>> appropriate. >>> >>> What I meant by the above phrase is that the order on which >> these services are applied are very important ans o should be >> the reporting. If you apply NAT and then layer 2/3 tunneling >> is different than the other way around. If the exporter does not >>> indicate this, you might get misleading data in the end. >>> >>> So, my point was if you are ptoviding these service you >> SHOULD be able to report them on the order they were applied. >> I think that's reasonable. >>> >>>> >>>>> >>>>> Each type field of the following IEs contain the type of operation >>>>> performed on the packet. The currently available types are: >>>>> >>>>> 1. - NAT >>>>> 2. - LSNAT >>>>> 3. - Twice NAT >>>>> 4. - Request Routing [KRR] >>>>> 5. - Outgoing L3 Tunnel >>>>> 6. - Incoming L3 Tunnel >>>>> 7. - Outgoing L2 Tunnel >>>>> 8. - Incoming L2 Tunnel >>>>> 9. - OPES (several sub-services here) >>>>> 10. - others... >>>>> >>>>> 6.12.1. Modified Source Address >>>>> >>>>> This information element contains the source address of the flow as >>>>> transmitted by the Exporter after a middlebox, OPES or >>>> similar service >>>> >>>> What is a OPES similar service? This is rather unclear, particularly >>>> if you request a MUST to support it. I prefer Paul's term >> 'redirecting >>>> packets/flows'. >>>> >>>> Juergen >>>> >>>>> was applied to the packet. It may be different than the >>>> source address >>>>> information element, which contains the original source >>>> address of the packet. >>>>> >>>>> The address is defined the same as for Source Address. >>>>> >>>>> Template ID: ### Field Type: ### Size: ### >>>>> >>>>> 6.12.2. Modified Source Port >>>>> >>>>> This information element contains the source port of the flow as >>>>> transmitted by the exporter after a middlebox, OPES or >>>> similar service >>>>> was applied to the packet. It may be different than the source port >>>>> information element, which contains the original source port >>>> of the packet. >>>>> >>>>> Template ID: ### Field Type: ### Size: ### >>>>> >>>>> 6.12.3. Modified Destination Address >>>>> >>>>> This information element contains the destination address >> of the flow >>>>> as transmitted by the exporter after a middlebox, OPES or similar >>>>> service was applied to the packet. It might be different than the >>>>> destination address information element, which contains >> the original >>>>> destination address of the packet. >>>>> >>>>> Template ID: ### Field Type: ### Size: ### >>>>> >> >> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Apr 15 13:15:29 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28463 for ; Mon, 15 Apr 2002 13:15:29 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16x9o4-00009b-00 for ipfix-list@mil.doit.wisc.edu; Mon, 15 Apr 2002 11:58:20 -0500 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16x9o3-00008X-00 for ipfix-data@net.doit.wisc.edu; Mon, 15 Apr 2002 11:58:19 -0500 Received: from riverstonenet.com (134.141.180.90 [134.141.180.90]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H23R9Z52; Mon, 15 Apr 2002 09:56:38 -0700 Message-ID: <3CBB0647.782DF513@riverstonenet.com> Date: Mon, 15 Apr 2002 12:56:39 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Reinaldo Penno , "Norseth, KC" , ipfix-data@net.doit.wisc.edu Subject: Re: [ipfix-data] Data doc - Section 7.11 References: <7B802811BE77D51189910002A55CFD2C01E6B73D@zsc3c032.us.nortel.com> <3369665.1018896906@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Maybe the picture you drew on your PC would be helpful. Paul Juergen Quittek wrote: > > Reinaldo, > > --On 12 April 2002 23:05 -0700 Reinaldo Penno wrote: > > > > > My concern with the "virtual" wording is that there is nothing > > "virtual" about the modified packet. Virtual implies the > > original/actual packet is more real than the modified one, > > Not the packet is virtual, but the header entry for source > or destination addresses may be virtual. If a NAT replaces > the source address by its own one while forwarding a packet, > then I think it is acceptable calling the modified source > address field in the leaving packet 'virtual'. > > Juergen > > > which is not. The modified packet can actually be more "real" > > if you are > > doing NAT, for instance. My opinion is that another terminology sould be used. > > > > As for the first question, imagine you receive a packet and you apply several services to it (NAT, insertion of content, whatever) and you want to report that (the services applied) on flow records. > > > > So, the order in which you apply these services matters and so the order in which you report them. As I said, if you apply NAT and then some firewall (possibly dropping the packet), but on the flow records you say the other way around, you will get the > > wrong picture. This is a easy example, but you can expand that for all other services that modify, drop, tunnel a packet. > > > > regards, > > > > Reinaldo > > > >> -----Original Message----- > >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > >> Sent: Friday, April 12, 2002 6:42 PM > >> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; > >> calato@riverstonenet.com > >> Cc: ipfix-data@net.doit.wisc.edu > >> Subject: RE: [ipfix-data] Data doc - Section 7.11 > >> > >> > >> Hi Reinaldo, > >> > >> With 'reflect the order of the operstions performed', do you mean > >> finding out what is the original and what the modified header field? > >> > >> I had a long discussion on the modified scheme versus the modified > >> scheme with Paul: > >> > >> The virtual scheme: > >> Any source-related header field in an arriving packet is called > >> actual. Any destination-reated header field in a leaving packet > >> is called actual. Actual values are the ones usually reported. > >> > >> If the value of a source-related header field in a leaving packet > >> differs from its value in the arriving packet, then this value is > >> called 'virtual'. If the value of a destination-related header > >> field in an arriving packet differs from its value in the leaving > >> packet, then this value is called 'virtual'. > >> > >> The modified scheme: > >> The value of a header field in an arriving packet is called original. > >> Original values are the ones usually reported. > >> If the value of a header field is modified in the leaving packet, > >> then it may be reported as the 'modified' value. > >> > >> In the end we preferred the virtual scheme. But please feel free > >> to convince us that the modified scheme is more appropriate. > >> > >> Juergen > >> > >> > >> --On 12 April 2002 11:45 -0700 Reinaldo Penno > >> wrote: > >> > >>> > >>> Hello Juergen, > >>> > >>> thanks for the comments. answers inline > >>> > >>>> -----Original Message----- > >>>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > >>>> Sent: Friday, April 12, 2002 4:30 AM > >>>> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; > >>>> calato@riverstonenet.com > >>>> Cc: ipfix-data@net.doit.wisc.edu > >>>> Subject: Re: [ipfix-data] Data doc - Section 7.11 > >>>> > >>>> > >>>> Hi Reinaldo, > >>>> > >>>> --On 09 April 2002 14:49 -0700 Reinaldo Penno > >>>> wrote: > >>>> > >>>>> > >>>>> In the data doc there was a part that Paul disagrees (or > >>>> used to) with me. I'm okay with finding other names anyway, > >>>> but IMO the description is better this way > >>>>> > >>>>> Basically I wanted to change section on NAT/source > >>>> virtual/destination virtual to: > >>>>> > >>>>> 7.11. Middlebox and other Services > >>>> > >>>> Having to choose between "Virtual Information" and "Middlebox and > >>>> other Services", I prefer the first one, because it is as general > >>>> as "other services" and it better reflects a meter's view: It does > >>>> not care that much about functions and applications/services running > >>>> additionally on the same box, it just cares about what such > >>>> applications do with packets or beterr with packet headers. Then > >>>> the concept of virtual and actual values of header fields seem so > >>>> be an adequate and sufficient view of what is happening. > >>> > >>> no problem, I can change the name. Do you think the > >> description is adequate? > >>> > >>>>> > >>>>> An exporter may be involved in providing services that require > >>>>> application level intelligence and/or transform or filter > >>>> content such > >>>> > >>>> I don't think there will be any router or other exporter device > >>>> that deserves the attribute 'intelligent'. These boxes are SO dumb! > >>>> Just work with them and you'll see :-) > >>> > >>> he!he! Some of them are a little more 'intelligent'.. > >>> > >>>> > >>>>> as middlebox and OPES respectively. > >>>>> > >>>>> When the exporter is involved on these types of services > >> the order of > >>>>> the IEs that contain information associated with these service MUST > >>>>> reflect the order of the operations performed. > >>>> > >>>> No. We should not have a MUST here. This would mean that you > >>>> cannot add middlebox functions to your box without updating the > >>>> IPFIX software/hardware. You could not run the same implementation > >>>> on boxes with different functionality. It is nice if the IPFIX > >>>> device reflects middlebox functions, but a MAY should be > >>>> appropriate. > >>> > >>> What I meant by the above phrase is that the order on which > >> these services are applied are very important ans o should be > >> the reporting. If you apply NAT and then layer 2/3 tunneling > >> is different than the other way around. If the exporter does not > >>> indicate this, you might get misleading data in the end. > >>> > >>> So, my point was if you are ptoviding these service you > >> SHOULD be able to report them on the order they were applied. > >> I think that's reasonable. > >>> > >>>> > >>>>> > >>>>> Each type field of the following IEs contain the type of operation > >>>>> performed on the packet. The currently available types are: > >>>>> > >>>>> 1. - NAT > >>>>> 2. - LSNAT > >>>>> 3. - Twice NAT > >>>>> 4. - Request Routing [KRR] > >>>>> 5. - Outgoing L3 Tunnel > >>>>> 6. - Incoming L3 Tunnel > >>>>> 7. - Outgoing L2 Tunnel > >>>>> 8. - Incoming L2 Tunnel > >>>>> 9. - OPES (several sub-services here) > >>>>> 10. - others... > >>>>> > >>>>> 6.12.1. Modified Source Address > >>>>> > >>>>> This information element contains the source address of the flow as > >>>>> transmitted by the Exporter after a middlebox, OPES or > >>>> similar service > >>>> > >>>> What is a OPES similar service? This is rather unclear, particularly > >>>> if you request a MUST to support it. I prefer Paul's term > >> 'redirecting > >>>> packets/flows'. > >>>> > >>>> Juergen > >>>> > >>>>> was applied to the packet. It may be different than the > >>>> source address > >>>>> information element, which contains the original source > >>>> address of the packet. > >>>>> > >>>>> The address is defined the same as for Source Address. > >>>>> > >>>>> Template ID: ### Field Type: ### Size: ### > >>>>> > >>>>> 6.12.2. Modified Source Port > >>>>> > >>>>> This information element contains the source port of the flow as > >>>>> transmitted by the exporter after a middlebox, OPES or > >>>> similar service > >>>>> was applied to the packet. It may be different than the source port > >>>>> information element, which contains the original source port > >>>> of the packet. > >>>>> > >>>>> Template ID: ### Field Type: ### Size: ### > >>>>> > >>>>> 6.12.3. Modified Destination Address > >>>>> > >>>>> This information element contains the destination address > >> of the flow > >>>>> as transmitted by the exporter after a middlebox, OPES or similar > >>>>> service was applied to the packet. It might be different than the > >>>>> destination address information element, which contains > >> the original > >>>>> destination address of the packet. > >>>>> > >>>>> Template ID: ### Field Type: ### Size: ### > >>>>> > >> > >> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Apr 15 13:29:58 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28973 for ; Mon, 15 Apr 2002 13:29:34 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16x9yp-0000R3-00 for ipfix-list@mil.doit.wisc.edu; Mon, 15 Apr 2002 12:09:28 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.us.nortel.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16x9yn-0000QJ-00 for ipfix-data@net.doit.wisc.edu; Mon, 15 Apr 2002 12:09:25 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FH4VV27638; Mon, 15 Apr 2002 10:04:32 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXM9WMV>; Mon, 15 Apr 2002 10:04:24 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C01E6BB30@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: Juergen Quittek , "Norseth, KC" , calato@riverstonenet.com Cc: ipfix-data@net.doit.wisc.edu Subject: RE: [ipfix-data] Data doc - Section 7.11 Date: Mon, 15 Apr 2002 10:04:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E49F.9269FE7C" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E49F.9269FE7C Content-Type: text/plain; charset="iso-8859-1" Juergen, if it's the packet, the src/dest address or whatever the argument remains. I think it's fair to say that "virtual" is not the best terminology to be used. I'm sure we can find a better term. As I said it implies that the original packet/header/field/whatever is more real (whatever this means) than the original/actual. Not to mention that in cases where you have twice/bi-directional NAT this can be a source of confusion. thanks, Reinaldo >-----Original Message----- >From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >Sent: Monday, April 15, 2002 9:55 AM >To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; >calato@riverstonenet.com >Cc: ipfix-data@net.doit.wisc.edu >Subject: RE: [ipfix-data] Data doc - Section 7.11 > > >Reinaldo, > >--On 12 April 2002 23:05 -0700 Reinaldo Penno wrote: > >> >> My concern with the "virtual" wording is that there is nothing >> "virtual" about the modified packet. Virtual implies the >> original/actual packet is more real than the modified one, > >Not the packet is virtual, but the header entry for source >or destination addresses may be virtual. If a NAT replaces >the source address by its own one while forwarding a packet, >then I think it is acceptable calling the modified source >address field in the leaving packet 'virtual'. > > Juergen > >> which is not. The modified packet can actually be more "real" >> if you are >> doing NAT, for instance. My opinion is that another >terminology sould be used. >> >> As for the first question, imagine you receive a packet and >you apply several services to it (NAT, insertion of content, >whatever) and you want to report that (the services applied) >on flow records. >> >> So, the order in which you apply these services matters and >so the order in which you report them. As I said, if you apply >NAT and then some firewall (possibly dropping the packet), but >on the flow records you say the other way around, you will get the >> wrong picture. This is a easy example, but you can expand >that for all other services that modify, drop, tunnel a packet. >> >> regards, >> >> Reinaldo >> >>> -----Original Message----- >>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >>> Sent: Friday, April 12, 2002 6:42 PM >>> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; >>> calato@riverstonenet.com >>> Cc: ipfix-data@net.doit.wisc.edu >>> Subject: RE: [ipfix-data] Data doc - Section 7.11 >>> >>> >>> Hi Reinaldo, >>> >>> With 'reflect the order of the operstions performed', do you mean >>> finding out what is the original and what the modified header field? >>> >>> I had a long discussion on the modified scheme versus the modified >>> scheme with Paul: >>> >>> The virtual scheme: >>> Any source-related header field in an arriving packet is called >>> actual. Any destination-reated header field in a leaving packet >>> is called actual. Actual values are the ones usually reported. >>> >>> If the value of a source-related header field in a leaving packet >>> differs from its value in the arriving packet, then this value is >>> called 'virtual'. If the value of a destination-related header >>> field in an arriving packet differs from its value in the leaving >>> packet, then this value is called 'virtual'. >>> >>> The modified scheme: >>> The value of a header field in an arriving packet is >called original. >>> Original values are the ones usually reported. >>> If the value of a header field is modified in the leaving packet, >>> then it may be reported as the 'modified' value. >>> >>> In the end we preferred the virtual scheme. But please feel free >>> to convince us that the modified scheme is more appropriate. >>> >>> Juergen >>> >>> >>> --On 12 April 2002 11:45 -0700 Reinaldo Penno >>> wrote: >>> >>>> >>>> Hello Juergen, >>>> >>>> thanks for the comments. answers inline >>>> >>>>> -----Original Message----- >>>>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >>>>> Sent: Friday, April 12, 2002 4:30 AM >>>>> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; >>>>> calato@riverstonenet.com >>>>> Cc: ipfix-data@net.doit.wisc.edu >>>>> Subject: Re: [ipfix-data] Data doc - Section 7.11 >>>>> >>>>> >>>>> Hi Reinaldo, >>>>> >>>>> --On 09 April 2002 14:49 -0700 Reinaldo Penno >>>>> wrote: >>>>> >>>>>> >>>>>> In the data doc there was a part that Paul disagrees (or >>>>> used to) with me. I'm okay with finding other names anyway, >>>>> but IMO the description is better this way >>>>>> >>>>>> Basically I wanted to change section on NAT/source >>>>> virtual/destination virtual to: >>>>>> >>>>>> 7.11. Middlebox and other Services >>>>> >>>>> Having to choose between "Virtual Information" and "Middlebox and >>>>> other Services", I prefer the first one, because it is as general >>>>> as "other services" and it better reflects a meter's view: It does >>>>> not care that much about functions and >applications/services running >>>>> additionally on the same box, it just cares about what such >>>>> applications do with packets or beterr with packet headers. Then >>>>> the concept of virtual and actual values of header fields seem so >>>>> be an adequate and sufficient view of what is happening. >>>> >>>> no problem, I can change the name. Do you think the >>> description is adequate? >>>> >>>>>> >>>>>> An exporter may be involved in providing services that require >>>>>> application level intelligence and/or transform or filter >>>>> content such >>>>> >>>>> I don't think there will be any router or other exporter device >>>>> that deserves the attribute 'intelligent'. These boxes >are SO dumb! >>>>> Just work with them and you'll see :-) >>>> >>>> he!he! Some of them are a little more 'intelligent'.. >>>> >>>>> >>>>>> as middlebox and OPES respectively. >>>>>> >>>>>> When the exporter is involved on these types of services >>> the order of >>>>>> the IEs that contain information associated with these >service MUST >>>>>> reflect the order of the operations performed. >>>>> >>>>> No. We should not have a MUST here. This would mean that you >>>>> cannot add middlebox functions to your box without updating the >>>>> IPFIX software/hardware. You could not run the same implementation >>>>> on boxes with different functionality. It is nice if the IPFIX >>>>> device reflects middlebox functions, but a MAY should be >>>>> appropriate. >>>> >>>> What I meant by the above phrase is that the order on which >>> these services are applied are very important ans o should be >>> the reporting. If you apply NAT and then layer 2/3 tunneling >>> is different than the other way around. If the exporter does not >>>> indicate this, you might get misleading data in the end. >>>> >>>> So, my point was if you are ptoviding these service you >>> SHOULD be able to report them on the order they were applied. >>> I think that's reasonable. >>>> >>>>> >>>>>> >>>>>> Each type field of the following IEs contain the type of >operation >>>>>> performed on the packet. The currently available types are: >>>>>> >>>>>> 1. - NAT >>>>>> 2. - LSNAT >>>>>> 3. - Twice NAT >>>>>> 4. - Request Routing [KRR] >>>>>> 5. - Outgoing L3 Tunnel >>>>>> 6. - Incoming L3 Tunnel >>>>>> 7. - Outgoing L2 Tunnel >>>>>> 8. - Incoming L2 Tunnel >>>>>> 9. - OPES (several sub-services here) >>>>>> 10. - others... >>>>>> >>>>>> 6.12.1. Modified Source Address >>>>>> >>>>>> This information element contains the source address of >the flow as >>>>>> transmitted by the Exporter after a middlebox, OPES or >>>>> similar service >>>>> >>>>> What is a OPES similar service? This is rather unclear, >particularly >>>>> if you request a MUST to support it. I prefer Paul's term >>> 'redirecting >>>>> packets/flows'. >>>>> >>>>> Juergen >>>>> >>>>>> was applied to the packet. It may be different than the >>>>> source address >>>>>> information element, which contains the original source >>>>> address of the packet. >>>>>> >>>>>> The address is defined the same as for Source Address. >>>>>> >>>>>> Template ID: ### Field Type: ### Size: ### >>>>>> >>>>>> 6.12.2. Modified Source Port >>>>>> >>>>>> This information element contains the source port of the flow as >>>>>> transmitted by the exporter after a middlebox, OPES or >>>>> similar service >>>>>> was applied to the packet. It may be different than the >source port >>>>>> information element, which contains the original source port >>>>> of the packet. >>>>>> >>>>>> Template ID: ### Field Type: ### Size: ### >>>>>> >>>>>> 6.12.3. Modified Destination Address >>>>>> >>>>>> This information element contains the destination address >>> of the flow >>>>>> as transmitted by the exporter after a middlebox, OPES or similar >>>>>> service was applied to the packet. It might be different than the >>>>>> destination address information element, which contains >>> the original >>>>>> destination address of the packet. >>>>>> >>>>>> Template ID: ### Field Type: ### Size: ### >>>>>> >>> >>> > > > ------_=_NextPart_001_01C1E49F.9269FE7C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-data] Data doc - Section 7.11

Juergen,

if it's the packet, the src/dest address or whatever = the argument remains. I think it's fair to say that "virtual" = is not the best terminology to be used. I'm sure we can find a better = term. As I said it implies that the original = packet/header/field/whatever is more real (whatever this means) than = the original/actual.

Not to mention that in cases where you have = twice/bi-directional NAT this can be a source of confusion.

thanks,

Reinaldo

>-----Original Message-----
>From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>Sent: Monday, April 15, 2002 9:55 AM
>To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, = KC;
>calato@riverstonenet.com
>Cc: ipfix-data@net.doit.wisc.edu
>Subject: RE: [ipfix-data] Data doc - Section = 7.11
>
>
>Reinaldo,
>
>--On 12 April 2002 23:05 -0700 Reinaldo Penno = wrote:
>
>>
>> My concern with the "virtual" = wording is that there is nothing
>> "virtual" about the modified = packet. Virtual implies the
>> original/actual packet is more real than = the modified one,
>
>Not the packet is virtual, but the header entry = for source
>or destination addresses may be virtual. If a = NAT replaces
>the source address by its own one while = forwarding a packet,
>then I think it is acceptable calling the = modified source
>address field in the leaving packet = 'virtual'.
>
>    Juergen
>
>> which is not. The modified packet can = actually be more "real"
>> if you are
>> doing NAT, for instance. My opinion is that = another
>terminology sould be used.
>>
>> As for the first question, imagine you = receive a packet and
>you apply several services to it (NAT, insertion = of content,
>whatever) and you want to report that (the = services applied)
>on flow records.
>>
>> So, the order in which you apply these = services matters and
>so the order in which you report them. As I = said, if you apply
>NAT and then some firewall (possibly dropping = the packet), but
>on the flow records you say the other way = around, you will get the
>> wrong picture. This is a easy example, but = you can expand
>that for all other services that modify, drop, = tunnel a packet.
>>
>> regards,
>>
>> Reinaldo
>>
>>> -----Original Message-----
>>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>>> Sent: Friday, April 12, 2002 6:42 = PM
>>> To: Penno, Reinaldo [SC9:T327:EXCH]; = Norseth, KC;
>>> calato@riverstonenet.com
>>> Cc: ipfix-data@net.doit.wisc.edu
>>> Subject: RE: [ipfix-data] Data doc - = Section 7.11
>>>
>>>
>>> Hi Reinaldo,
>>>
>>> With 'reflect the order of the = operstions performed', do you mean
>>> finding out what is the original and = what the modified header field?
>>>
>>> I had a long discussion on the modified = scheme versus the modified
>>> scheme with Paul:
>>>
>>> The virtual scheme:
>>>  Any source-related header field = in an arriving packet is called
>>>  actual. Any destination-reated = header field in a leaving packet
>>>  is called actual. Actual values = are the ones usually reported.
>>>
>>>  If the value of a source-related = header field in a leaving packet
>>>  differs from its value in the = arriving packet, then this value is
>>>  called 'virtual'. If the value of = a destination-related header
>>>  field in an arriving packet = differs from its value in the leaving
>>>  packet, then this value is called = 'virtual'.
>>>
>>> The modified scheme:
>>>  The value of a header field in an = arriving packet is
>called original.
>>>  Original values are the ones = usually reported.
>>>  If the value of a header field is = modified in the leaving packet,
>>>  then it may be reported as the = 'modified' value.
>>>
>>> In the end we preferred the virtual = scheme. But please feel free
>>> to convince us that the modified scheme = is more appropriate.
>>>
>>>    Juergen
>>>
>>>
>>> --On 12 April 2002 11:45 -0700 Reinaldo = Penno
>>> = <reinaldo_penno@nortelnetworks.com> wrote:
>>>
>>>>
>>>> Hello Juergen,
>>>>
>>>> thanks for the comments. answers = inline
>>>>
>>>>> -----Original = Message-----
>>>>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>>>>> Sent: Friday, April 12, 2002 = 4:30 AM
>>>>> To: Penno, Reinaldo = [SC9:T327:EXCH]; Norseth, KC;
>>>>> calato@riverstonenet.com
>>>>> Cc: = ipfix-data@net.doit.wisc.edu
>>>>> Subject: Re: [ipfix-data] Data = doc - Section 7.11
>>>>>
>>>>>
>>>>> Hi Reinaldo,
>>>>>
>>>>> --On 09 April 2002 14:49 -0700 = Reinaldo Penno
>>>>> = <reinaldo_penno@nortelnetworks.com> wrote:
>>>>>
>>>>>>
>>>>>> In the data doc there was a = part that Paul disagrees (or
>>>>> used to) with me. I'm okay with = finding other names anyway,
>>>>> but IMO the description is = better this way
>>>>>>
>>>>>> Basically I wanted to = change section on NAT/source
>>>>> virtual/destination virtual = to:
>>>>>>
>>>>>> 7.11. Middlebox and other = Services
>>>>>
>>>>> Having to choose between = "Virtual Information" and "Middlebox and
>>>>> other Services", I prefer = the first one, because it is as general
>>>>> as "other services" = and it better reflects a meter's view: It does
>>>>> not care that much about = functions and
>applications/services running
>>>>> additionally on the same box, = it just cares about what such
>>>>> applications do with packets or = beterr with packet headers. Then
>>>>> the concept of virtual and = actual values of header fields seem so
>>>>> be an adequate and sufficient = view of what is happening.
>>>>
>>>> no problem, I can change the name. = Do you think the
>>> description is adequate?
>>>>
>>>>>>
>>>>>> An exporter may be involved = in providing services that require
>>>>>> application level = intelligence and/or transform or filter
>>>>> content such
>>>>>
>>>>> I don't think there will be any = router or other exporter device
>>>>> that deserves the attribute = 'intelligent'. These boxes
>are SO dumb!
>>>>> Just work with them and you'll = see :-)
>>>>
>>>> he!he! Some of them are a little = more 'intelligent'..
>>>>
>>>>>
>>>>>> as middlebox and OPES = respectively.
>>>>>>
>>>>>> When the exporter is = involved on these types of services
>>> the order of
>>>>>> the IEs that contain = information associated with these
>service MUST
>>>>>> reflect the order of the = operations performed.
>>>>>
>>>>> No. We should not have a MUST = here. This would mean that you
>>>>> cannot add middlebox functions = to your box without updating the
>>>>> IPFIX software/hardware. You = could not run the same implementation
>>>>> on boxes with different = functionality. It is nice if the IPFIX
>>>>> device reflects middlebox = functions, but a MAY should be
>>>>> appropriate.
>>>>
>>>> What I meant by the above phrase is = that the order on which
>>> these services are applied are very = important ans o should be
>>> the reporting. If you apply NAT and = then layer 2/3 tunneling
>>> is different than the other way around. = If the exporter does not
>>>> indicate this, you might get = misleading data in the end.
>>>>
>>>> So, my point was if you are = ptoviding these service you
>>> SHOULD be able to report them on the = order they were applied.
>>> I think that's reasonable.
>>>>
>>>>>
>>>>>>
>>>>>> Each type field of the = following IEs contain the type of
>operation
>>>>>> performed on the packet. = The currently available types are:
>>>>>>
>>>>>> 1. - NAT
>>>>>> 2. - LSNAT
>>>>>> 3. - Twice NAT
>>>>>> 4. - Request Routing = [KRR]
>>>>>> 5. - Outgoing L3 = Tunnel
>>>>>> 6. - Incoming L3 = Tunnel
>>>>>> 7. - Outgoing L2 = Tunnel
>>>>>> 8. - Incoming L2 = Tunnel
>>>>>> 9. - OPES (several = sub-services here)
>>>>>> 10. - others...
>>>>>>
>>>>>> 6.12.1.  Modified = Source Address
>>>>>>
>>>>>> This information element = contains the source address of
>the flow as
>>>>>> transmitted by the Exporter = after a middlebox, OPES or
>>>>> similar service
>>>>>
>>>>> What is a OPES similar service? = This is rather unclear,
>particularly
>>>>> if you request a MUST to = support it. I prefer Paul's term
>>> 'redirecting
>>>>> packets/flows'.
>>>>>
>>>>>    = Juergen
>>>>>
>>>>>> was applied to the packet. = It may be different than the
>>>>> source address
>>>>>> information element, which = contains the original source
>>>>> address of the packet.
>>>>>>
>>>>>> The address is defined the = same as for Source Address.
>>>>>>
>>>>>> Template ID: = ###   Field Type: ###   Size: ###
>>>>>>
>>>>>> 6.12.2.  Modified = Source Port
>>>>>>
>>>>>> This information element = contains the source port of the flow as
>>>>>> transmitted by the exporter = after a middlebox, OPES or
>>>>> similar service
>>>>>> was applied to the packet. = It may be different than the
>source port
>>>>>> information element, which = contains the original source port
>>>>> of the packet.
>>>>>>
>>>>>> Template ID: = ###   Field Type: ###   Size: ###
>>>>>>
>>>>>> 6.12.3.  Modified = Destination Address
>>>>>>
>>>>>> This information element = contains the destination address
>>> of the flow
>>>>>> as transmitted by the = exporter after a middlebox, OPES or similar
>>>>>> service was applied to the = packet. It might be different than the
>>>>>> destination address = information element, which contains
>>> the original
>>>>>> destination address of the = packet.
>>>>>>
>>>>>> Template ID: = ###   Field Type: ###   Size: ###
>>>>>>
>>>
>>>
>
>
>

------_=_NextPart_001_01C1E49F.9269FE7C-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Apr 15 13:31:21 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29014 for ; Mon, 15 Apr 2002 13:31:11 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16xA6L-0000dK-00 for ipfix-list@mil.doit.wisc.edu; Mon, 15 Apr 2002 12:17:13 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.us.nortel.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16xA6I-0000cT-00 for ipfix-data@net.doit.wisc.edu; Mon, 15 Apr 2002 12:17:10 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FHCLV28019; Mon, 15 Apr 2002 10:12:22 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXM9WQK>; Mon, 15 Apr 2002 10:12:14 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C01E6BB68@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com, Juergen Quittek Cc: "Norseth, KC" , ipfix-data@net.doit.wisc.edu Subject: RE: [ipfix-data] Data doc - Section 7.11 - Suggestions Date: Mon, 15 Apr 2002 10:12:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E4A0.ACFA30E4" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E4A0.ACFA30E4 Content-Type: text/plain; charset="iso-8859-1" Instead of "virtual", two suggestion for terminology from 2663, so we are consistent with the current NAT terminology. 1 - "translated" (this is the easiest one, comes from the NAT acronym) 2 - "mapped" (comes from the terminology used in 2663) regards, Reinaldo >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Monday, April 15, 2002 9:57 AM >To: Juergen Quittek >Cc: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; >ipfix-data@net.doit.wisc.edu >Subject: Re: [ipfix-data] Data doc - Section 7.11 > > > >Maybe the picture you drew on your PC would >be helpful. > >Paul > >Juergen Quittek wrote: >> >> Reinaldo, >> >> --On 12 April 2002 23:05 -0700 Reinaldo Penno wrote: >> >> > >> > My concern with the "virtual" wording is that there is nothing >> > "virtual" about the modified packet. Virtual implies the >> > original/actual packet is more real than the modified one, >> >> Not the packet is virtual, but the header entry for source >> or destination addresses may be virtual. If a NAT replaces >> the source address by its own one while forwarding a packet, >> then I think it is acceptable calling the modified source >> address field in the leaving packet 'virtual'. >> >> Juergen >> >> > which is not. The modified packet can actually be more "real" >> > if you are >> > doing NAT, for instance. My opinion is that another >terminology sould be used. >> > >> > As for the first question, imagine you receive a packet >and you apply several services to it (NAT, insertion of >content, whatever) and you want to report that (the services >applied) on flow records. >> > >> > So, the order in which you apply these services matters >and so the order in which you report them. As I said, if you >apply NAT and then some firewall (possibly dropping the >packet), but on the flow records you say the other way around, >you will get the >> > wrong picture. This is a easy example, but you can expand >that for all other services that modify, drop, tunnel a packet. >> > >> > regards, >> > >> > Reinaldo >> > >> >> -----Original Message----- >> >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> >> Sent: Friday, April 12, 2002 6:42 PM >> >> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; >> >> calato@riverstonenet.com >> >> Cc: ipfix-data@net.doit.wisc.edu >> >> Subject: RE: [ipfix-data] Data doc - Section 7.11 >> >> >> >> >> >> Hi Reinaldo, >> >> >> >> With 'reflect the order of the operstions performed', do you mean >> >> finding out what is the original and what the modified >header field? >> >> >> >> I had a long discussion on the modified scheme versus the modified >> >> scheme with Paul: >> >> >> >> The virtual scheme: >> >> Any source-related header field in an arriving packet is called >> >> actual. Any destination-reated header field in a leaving packet >> >> is called actual. Actual values are the ones usually reported. >> >> >> >> If the value of a source-related header field in a leaving packet >> >> differs from its value in the arriving packet, then this value is >> >> called 'virtual'. If the value of a destination-related header >> >> field in an arriving packet differs from its value in the leaving >> >> packet, then this value is called 'virtual'. >> >> >> >> The modified scheme: >> >> The value of a header field in an arriving packet is >called original. >> >> Original values are the ones usually reported. >> >> If the value of a header field is modified in the leaving packet, >> >> then it may be reported as the 'modified' value. >> >> >> >> In the end we preferred the virtual scheme. But please feel free >> >> to convince us that the modified scheme is more appropriate. >> >> >> >> Juergen >> >> >> >> >> >> --On 12 April 2002 11:45 -0700 Reinaldo Penno >> >> wrote: >> >> >> >>> >> >>> Hello Juergen, >> >>> >> >>> thanks for the comments. answers inline >> >>> >> >>>> -----Original Message----- >> >>>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> >>>> Sent: Friday, April 12, 2002 4:30 AM >> >>>> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; >> >>>> calato@riverstonenet.com >> >>>> Cc: ipfix-data@net.doit.wisc.edu >> >>>> Subject: Re: [ipfix-data] Data doc - Section 7.11 >> >>>> >> >>>> >> >>>> Hi Reinaldo, >> >>>> >> >>>> --On 09 April 2002 14:49 -0700 Reinaldo Penno >> >>>> wrote: >> >>>> >> >>>>> >> >>>>> In the data doc there was a part that Paul disagrees (or >> >>>> used to) with me. I'm okay with finding other names anyway, >> >>>> but IMO the description is better this way >> >>>>> >> >>>>> Basically I wanted to change section on NAT/source >> >>>> virtual/destination virtual to: >> >>>>> >> >>>>> 7.11. Middlebox and other Services >> >>>> >> >>>> Having to choose between "Virtual Information" and >"Middlebox and >> >>>> other Services", I prefer the first one, because it is >as general >> >>>> as "other services" and it better reflects a meter's >view: It does >> >>>> not care that much about functions and >applications/services running >> >>>> additionally on the same box, it just cares about what such >> >>>> applications do with packets or beterr with packet headers. Then >> >>>> the concept of virtual and actual values of header >fields seem so >> >>>> be an adequate and sufficient view of what is happening. >> >>> >> >>> no problem, I can change the name. Do you think the >> >> description is adequate? >> >>> >> >>>>> >> >>>>> An exporter may be involved in providing services that require >> >>>>> application level intelligence and/or transform or filter >> >>>> content such >> >>>> >> >>>> I don't think there will be any router or other exporter device >> >>>> that deserves the attribute 'intelligent'. These boxes >are SO dumb! >> >>>> Just work with them and you'll see :-) >> >>> >> >>> he!he! Some of them are a little more 'intelligent'.. >> >>> >> >>>> >> >>>>> as middlebox and OPES respectively. >> >>>>> >> >>>>> When the exporter is involved on these types of services >> >> the order of >> >>>>> the IEs that contain information associated with these >service MUST >> >>>>> reflect the order of the operations performed. >> >>>> >> >>>> No. We should not have a MUST here. This would mean that you >> >>>> cannot add middlebox functions to your box without updating the >> >>>> IPFIX software/hardware. You could not run the same >implementation >> >>>> on boxes with different functionality. It is nice if the IPFIX >> >>>> device reflects middlebox functions, but a MAY should be >> >>>> appropriate. >> >>> >> >>> What I meant by the above phrase is that the order on which >> >> these services are applied are very important ans o should be >> >> the reporting. If you apply NAT and then layer 2/3 tunneling >> >> is different than the other way around. If the exporter does not >> >>> indicate this, you might get misleading data in the end. >> >>> >> >>> So, my point was if you are ptoviding these service you >> >> SHOULD be able to report them on the order they were applied. >> >> I think that's reasonable. >> >>> >> >>>> >> >>>>> >> >>>>> Each type field of the following IEs contain the type >of operation >> >>>>> performed on the packet. The currently available types are: >> >>>>> >> >>>>> 1. - NAT >> >>>>> 2. - LSNAT >> >>>>> 3. - Twice NAT >> >>>>> 4. - Request Routing [KRR] >> >>>>> 5. - Outgoing L3 Tunnel >> >>>>> 6. - Incoming L3 Tunnel >> >>>>> 7. - Outgoing L2 Tunnel >> >>>>> 8. - Incoming L2 Tunnel >> >>>>> 9. - OPES (several sub-services here) >> >>>>> 10. - others... >> >>>>> >> >>>>> 6.12.1. Modified Source Address >> >>>>> >> >>>>> This information element contains the source address >of the flow as >> >>>>> transmitted by the Exporter after a middlebox, OPES or >> >>>> similar service >> >>>> >> >>>> What is a OPES similar service? This is rather unclear, >particularly >> >>>> if you request a MUST to support it. I prefer Paul's term >> >> 'redirecting >> >>>> packets/flows'. >> >>>> >> >>>> Juergen >> >>>> >> >>>>> was applied to the packet. It may be different than the >> >>>> source address >> >>>>> information element, which contains the original source >> >>>> address of the packet. >> >>>>> >> >>>>> The address is defined the same as for Source Address. >> >>>>> >> >>>>> Template ID: ### Field Type: ### Size: ### >> >>>>> >> >>>>> 6.12.2. Modified Source Port >> >>>>> >> >>>>> This information element contains the source port of >the flow as >> >>>>> transmitted by the exporter after a middlebox, OPES or >> >>>> similar service >> >>>>> was applied to the packet. It may be different than >the source port >> >>>>> information element, which contains the original source port >> >>>> of the packet. >> >>>>> >> >>>>> Template ID: ### Field Type: ### Size: ### >> >>>>> >> >>>>> 6.12.3. Modified Destination Address >> >>>>> >> >>>>> This information element contains the destination address >> >> of the flow >> >>>>> as transmitted by the exporter after a middlebox, OPES >or similar >> >>>>> service was applied to the packet. It might be >different than the >> >>>>> destination address information element, which contains >> >> the original >> >>>>> destination address of the packet. >> >>>>> >> >>>>> Template ID: ### Field Type: ### Size: ### >> >>>>> >> >> >> >> > ------_=_NextPart_001_01C1E4A0.ACFA30E4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-data] Data doc - Section 7.11 - Suggestions

Instead of "virtual", two suggestion for = terminology from 2663, so we are consistent with the current NAT = terminology.

1 - "translated" (this is the easiest one, = comes from the NAT acronym)
2 - "mapped" (comes from the terminology = used in 2663)

regards,

Reinaldo

>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>Sent: Monday, April 15, 2002 9:57 AM
>To: Juergen Quittek
>Cc: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, = KC;
>ipfix-data@net.doit.wisc.edu
>Subject: Re: [ipfix-data] Data doc - Section = 7.11
>
>
>
>Maybe the picture you drew on your PC = would
>be helpful.
>
>Paul
>
>Juergen Quittek wrote:
>>
>> Reinaldo,
>>
>> --On 12 April 2002 23:05 -0700 Reinaldo = Penno wrote:
>>
>> >
>> > My concern with the = "virtual" wording is that there is nothing
>> > "virtual" about the modified = packet. Virtual implies the
>> > original/actual packet is more real = than the modified one,
>>
>> Not the packet is virtual, but the header = entry for source
>> or destination addresses may be virtual. If = a NAT replaces
>> the source address by its own one while = forwarding a packet,
>> then I think it is acceptable calling the = modified source
>> address field in the leaving packet = 'virtual'.
>>
>>     Juergen
>>
>> > which is not. The modified packet can = actually be more "real"
>> > if you are
>> > doing NAT, for instance. My opinion is = that another
>terminology sould be used.
>> >
>> > As for the first question, imagine you = receive a packet
>and you apply several services to it (NAT, = insertion of
>content, whatever) and you want to report that = (the services
>applied) on flow records.
>> >
>> > So, the order in which you apply these = services matters
>and so the order in which you report them. As I = said, if you
>apply NAT and then some firewall (possibly = dropping the
>packet), but on the flow records you say the = other way around,
>you will get the
>> > wrong picture. This is a easy example, = but you can expand
>that for all other services that modify, drop, = tunnel a packet.
>> >
>> > regards,
>> >
>> > Reinaldo
>> >
>> >> -----Original Message-----
>> >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>> >> Sent: Friday, April 12, 2002 6:42 = PM
>> >> To: Penno, Reinaldo = [SC9:T327:EXCH]; Norseth, KC;
>> >> calato@riverstonenet.com
>> >> Cc: = ipfix-data@net.doit.wisc.edu
>> >> Subject: RE: [ipfix-data] Data doc = - Section 7.11
>> >>
>> >>
>> >> Hi Reinaldo,
>> >>
>> >> With 'reflect the order of the = operstions performed', do you mean
>> >> finding out what is the original = and what the modified
>header field?
>> >>
>> >> I had a long discussion on the = modified scheme versus the modified
>> >> scheme with Paul:
>> >>
>> >> The virtual scheme:
>> >>  Any source-related header = field in an arriving packet is called
>> >>  actual. Any = destination-reated header field in a leaving packet
>> >>  is called actual. Actual = values are the ones usually reported.
>> >>
>> >>  If the value of a = source-related header field in a leaving packet
>> >>  differs from its value in = the arriving packet, then this value is
>> >>  called 'virtual'. If the = value of a destination-related header
>> >>  field in an arriving packet = differs from its value in the leaving
>> >>  packet, then this value is = called 'virtual'.
>> >>
>> >> The modified scheme:
>> >>  The value of a header field = in an arriving packet is
>called original.
>> >>  Original values are the ones = usually reported.
>> >>  If the value of a header = field is modified in the leaving packet,
>> >>  then it may be reported as = the 'modified' value.
>> >>
>> >> In the end we preferred the = virtual scheme. But please feel free
>> >> to convince us that the modified = scheme is more appropriate.
>> >>
>> >>    Juergen
>> >>
>> >>
>> >> --On 12 April 2002 11:45 -0700 = Reinaldo Penno
>> >> = <reinaldo_penno@nortelnetworks.com> wrote:
>> >>
>> >>>
>> >>> Hello Juergen,
>> >>>
>> >>> thanks for the comments. = answers inline
>> >>>
>> >>>> -----Original = Message-----
>> >>>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>> >>>> Sent: Friday, April 12, = 2002 4:30 AM
>> >>>> To: Penno, Reinaldo = [SC9:T327:EXCH]; Norseth, KC;
>> >>>> = calato@riverstonenet.com
>> >>>> Cc: = ipfix-data@net.doit.wisc.edu
>> >>>> Subject: Re: [ipfix-data] = Data doc - Section 7.11
>> >>>>
>> >>>>
>> >>>> Hi Reinaldo,
>> >>>>
>> >>>> --On 09 April 2002 14:49 = -0700 Reinaldo Penno
>> >>>> = <reinaldo_penno@nortelnetworks.com> wrote:
>> >>>>
>> >>>>>
>> >>>>> In the data doc there = was a part that Paul disagrees (or
>> >>>> used to) with me. I'm okay = with finding other names anyway,
>> >>>> but IMO the description is = better this way
>> >>>>>
>> >>>>> Basically I wanted to = change section on NAT/source
>> >>>> virtual/destination = virtual to:
>> >>>>>
>> >>>>> 7.11. Middlebox and = other Services
>> >>>>
>> >>>> Having to choose between = "Virtual Information" and
>"Middlebox and
>> >>>> other Services", I = prefer the first one, because it is
>as general
>> >>>> as "other = services" and it better reflects a meter's
>view: It does
>> >>>> not care that much about = functions and
>applications/services running
>> >>>> additionally on the same = box, it just cares about what such
>> >>>> applications do with = packets or beterr with packet headers. Then
>> >>>> the concept of virtual and = actual values of header
>fields seem so
>> >>>> be an adequate and = sufficient view of what is happening.
>> >>>
>> >>> no problem, I can change the = name. Do you think the
>> >> description is adequate?
>> >>>
>> >>>>>
>> >>>>> An exporter may be = involved in providing services that require
>> >>>>> application level = intelligence and/or transform or filter
>> >>>> content such
>> >>>>
>> >>>> I don't think there will = be any router or other exporter device
>> >>>> that deserves the = attribute 'intelligent'. These boxes
>are SO dumb!
>> >>>> Just work with them and = you'll see :-)
>> >>>
>> >>> he!he! Some of them are a = little more 'intelligent'..
>> >>>
>> >>>>
>> >>>>> as middlebox and OPES = respectively.
>> >>>>>
>> >>>>> When the exporter is = involved on these types of services
>> >> the order of
>> >>>>> the IEs that contain = information associated with these
>service MUST
>> >>>>> reflect the order of = the operations performed.
>> >>>>
>> >>>> No. We should not have a = MUST here. This would mean that you
>> >>>> cannot add middlebox = functions to your box without updating the
>> >>>> IPFIX software/hardware. = You could not run the same
>implementation
>> >>>> on boxes with different = functionality. It is nice if the IPFIX
>> >>>> device reflects middlebox = functions, but a MAY should be
>> >>>> appropriate.
>> >>>
>> >>> What I meant by the above = phrase is that the order on which
>> >> these services are applied are = very important ans o should be
>> >> the reporting. If you apply NAT = and then layer 2/3 tunneling
>> >> is different than the other way = around. If the exporter does not
>> >>> indicate this, you might get = misleading data in the end.
>> >>>
>> >>> So, my point was if you are = ptoviding these service you
>> >> SHOULD be able to report them on = the order they were applied.
>> >> I think that's reasonable.
>> >>>
>> >>>>
>> >>>>>
>> >>>>> Each type field of the = following IEs contain the type
>of operation
>> >>>>> performed on the = packet. The currently available types are:
>> >>>>>
>> >>>>> 1. - NAT
>> >>>>> 2. - LSNAT
>> >>>>> 3. - Twice NAT
>> >>>>> 4. - Request Routing = [KRR]
>> >>>>> 5. - Outgoing L3 = Tunnel
>> >>>>> 6. - Incoming L3 = Tunnel
>> >>>>> 7. - Outgoing L2 = Tunnel
>> >>>>> 8. - Incoming L2 = Tunnel
>> >>>>> 9. - OPES (several = sub-services here)
>> >>>>> 10. - others...
>> >>>>>
>> >>>>> 6.12.1.  Modified = Source Address
>> >>>>>
>> >>>>> This information = element contains the source address
>of the flow as
>> >>>>> transmitted by the = Exporter after a middlebox, OPES or
>> >>>> similar service
>> >>>>
>> >>>> What is a OPES similar = service? This is rather unclear,
>particularly
>> >>>> if you request a MUST to = support it. I prefer Paul's term
>> >> 'redirecting
>> >>>> packets/flows'.
>> >>>>
>> >>>>    = Juergen
>> >>>>
>> >>>>> was applied to the = packet. It may be different than the
>> >>>> source address
>> >>>>> information element, = which contains the original source
>> >>>> address of the = packet.
>> >>>>>
>> >>>>> The address is defined = the same as for Source Address.
>> >>>>>
>> >>>>> Template ID: = ###   Field Type: ###   Size: ###
>> >>>>>
>> >>>>> 6.12.2.  Modified = Source Port
>> >>>>>
>> >>>>> This information = element contains the source port of
>the flow as
>> >>>>> transmitted by the = exporter after a middlebox, OPES or
>> >>>> similar service
>> >>>>> was applied to the = packet. It may be different than
>the source port
>> >>>>> information element, = which contains the original source port
>> >>>> of the packet.
>> >>>>>
>> >>>>> Template ID: = ###   Field Type: ###   Size: ###
>> >>>>>
>> >>>>> 6.12.3.  Modified = Destination Address
>> >>>>>
>> >>>>> This information = element contains the destination address
>> >> of the flow
>> >>>>> as transmitted by the = exporter after a middlebox, OPES
>or similar
>> >>>>> service was applied to = the packet. It might be
>different than the
>> >>>>> destination address = information element, which contains
>> >> the original
>> >>>>> destination address of = the packet.
>> >>>>>
>> >>>>> Template ID: = ###   Field Type: ###   Size: ###
>> >>>>>
>> >>
>> >>
>

------_=_NextPart_001_01C1E4A0.ACFA30E4-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Apr 15 13:38:31 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29354 for ; Mon, 15 Apr 2002 13:38:27 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16xADI-0000m2-00 for ipfix-list@mil.doit.wisc.edu; Mon, 15 Apr 2002 12:24:24 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.us.nortel.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16xADF-0000lO-00 for ipfix-data@net.doit.wisc.edu; Mon, 15 Apr 2002 12:24:21 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FHJXV28671; Mon, 15 Apr 2002 10:19:33 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXM9WV5>; Mon, 15 Apr 2002 10:19:25 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C01E6BB8F@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com Cc: Juergen Quittek , "Norseth, KC" , ipfix-data@net.doit.wisc.edu Subject: RE: [ipfix-data] Data doc - Section 7.11 Date: Mon, 15 Apr 2002 10:19:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E4A1.ADD14448" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E4A1.ADD14448 Content-Type: text/plain; charset="iso-8859-1" Hello Paul, correct. SHOULD or MAY could be used in the text. thanks, Reinaldo >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Monday, April 15, 2002 8:41 AM >To: Penno, Reinaldo [SC9:T327:EXCH] >Cc: Juergen Quittek; Norseth, KC; ipfix-data@net.doit.wisc.edu >Subject: Re: [ipfix-data] Data doc - Section 7.11 > > >Reinaldo Penno wrote: >> >> My concern with the "virtual" wording is that there is nothing >> "virtual" about the modified packet. Virtual implies the >> original/actual packet is more real than the modified one, which is >> not. The modified packet can actually be more "real" if you are doing >> NAT, for instance. My opinion is that another terminology sould be >> used. >> >> As for the first question, imagine you receive a packet and you apply >> several services to it (NAT, insertion of content, whatever) and you >> want to report that (the services applied) on flow records. >> >> So, the order in which you apply these services matters and so the >> order in which you report them. As I said, if you apply NAT and then >> some firewall (possibly dropping the packet), but on the flow records >> you say the other way around, you will get the wrong picture. This is >> a easy example, but you can expand that for all other services that >> modify, drop, tunnel a packet. > > If you are saying that if more than one of these fields > are reported in a flow then they must be in order,that > seems reasonable to me too. But we are NOT saying you must > report the fields in the first place, correct? > >> >> regards, >> >> Reinaldo >> >> >-----Original Message----- >> >From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> >Sent: Friday, April 12, 2002 6:42 PM >> >To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; >> >calato@riverstonenet.com >> >Cc: ipfix-data@net.doit.wisc.edu >> >Subject: RE: [ipfix-data] Data doc - Section 7.11 >> > >> > >> >Hi Reinaldo, >> > >> >With 'reflect the order of the operstions performed', do you mean >> >finding out what is the original and what the modified header field? >> > >> >I had a long discussion on the modified scheme versus the modified >> >scheme with Paul: >> > >> >The virtual scheme: >> > Any source-related header field in an arriving packet is called >> > actual. Any destination-reated header field in a leaving packet >> > is called actual. Actual values are the ones usually reported. >> > >> > If the value of a source-related header field in a leaving packet >> > differs from its value in the arriving packet, then this value is >> > called 'virtual'. If the value of a destination-related header >> > field in an arriving packet differs from its value in the leaving >> > packet, then this value is called 'virtual'. >> > >> >The modified scheme: >> > The value of a header field in an arriving packet is called >> original. >> > Original values are the ones usually reported. >> > If the value of a header field is modified in the leaving packet, >> > then it may be reported as the 'modified' value. >> > >> >In the end we preferred the virtual scheme. But please feel free >> >to convince us that the modified scheme is more appropriate. >> > >> > Juergen >> > >> > >> >--On 12 April 2002 11:45 -0700 Reinaldo Penno >> > wrote: >> > >> >> >> >> Hello Juergen, >> >> >> >> thanks for the comments. answers inline >> >> >> >>> -----Original Message----- >> >>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> >>> Sent: Friday, April 12, 2002 4:30 AM >> >>> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; >> >>> calato@riverstonenet.com >> >>> Cc: ipfix-data@net.doit.wisc.edu >> >>> Subject: Re: [ipfix-data] Data doc - Section 7.11 >> >>> >> >>> >> >>> Hi Reinaldo, >> >>> >> >>> --On 09 April 2002 14:49 -0700 Reinaldo Penno >> >>> wrote: >> >>> >> >>>> >> >>>> In the data doc there was a part that Paul disagrees (or >> >>> used to) with me. I'm okay with finding other names anyway, >> >>> but IMO the description is better this way >> >>>> >> >>>> Basically I wanted to change section on NAT/source >> >>> virtual/destination virtual to: >> >>>> >> >>>> 7.11. Middlebox and other Services >> >>> >> >>> Having to choose between "Virtual Information" and "Middlebox and >> >>> other Services", I prefer the first one, because it is as general >> >>> as "other services" and it better reflects a meter's >view: It does >> >> >>> not care that much about functions and applications/services >> running >> >>> additionally on the same box, it just cares about what such >> >>> applications do with packets or beterr with packet headers. Then >> >>> the concept of virtual and actual values of header fields seem so >> >>> be an adequate and sufficient view of what is happening. >> >> >> >> no problem, I can change the name. Do you think the >> >description is adequate? >> >> >> >>>> >> >>>> An exporter may be involved in providing services that require >> >>>> application level intelligence and/or transform or filter >> >>> content such >> >>> >> >>> I don't think there will be any router or other exporter device >> >>> that deserves the attribute 'intelligent'. These boxes are SO >> dumb! >> >>> Just work with them and you'll see :-) >> >> >> >> he!he! Some of them are a little more 'intelligent'.. >> >> >> >>> >> >>>> as middlebox and OPES respectively. >> >>>> >> >>>> When the exporter is involved on these types of services >> >the order of >> >>>> the IEs that contain information associated with these service >> MUST >> >>>> reflect the order of the operations performed. >> >>> >> >>> No. We should not have a MUST here. This would mean that you >> >>> cannot add middlebox functions to your box without updating the >> >>> IPFIX software/hardware. You could not run the same >implementation >> >> >>> on boxes with different functionality. It is nice if the IPFIX >> >>> device reflects middlebox functions, but a MAY should be >> >>> appropriate. >> >> >> >> What I meant by the above phrase is that the order on which >> >these services are applied are very important ans o should be >> >the reporting. If you apply NAT and then layer 2/3 tunneling >> >is different than the other way around. If the exporter does not >> >> indicate this, you might get misleading data in the end. >> >> >> >> So, my point was if you are ptoviding these service you >> >SHOULD be able to report them on the order they were applied. >> >I think that's reasonable. >> >> >> >>> >> >>>> >> >>>> Each type field of the following IEs contain the type of >> operation >> >>>> performed on the packet. The currently available types are: >> >>>> >> >>>> 1. - NAT >> >>>> 2. - LSNAT >> >>>> 3. - Twice NAT >> >>>> 4. - Request Routing [KRR] >> >>>> 5. - Outgoing L3 Tunnel >> >>>> 6. - Incoming L3 Tunnel >> >>>> 7. - Outgoing L2 Tunnel >> >>>> 8. - Incoming L2 Tunnel >> >>>> 9. - OPES (several sub-services here) >> >>>> 10. - others... >> >>>> >> >>>> 6.12.1. Modified Source Address >> >>>> >> >>>> This information element contains the source address of the flow >> as >> >>>> transmitted by the Exporter after a middlebox, OPES or >> >>> similar service >> >>> >> >>> What is a OPES similar service? This is rather unclear, >> particularly >> >>> if you request a MUST to support it. I prefer Paul's term >> >'redirecting >> >>> packets/flows'. >> >>> >> >>> Juergen >> >>> >> >>>> was applied to the packet. It may be different than the >> >>> source address >> >>>> information element, which contains the original source >> >>> address of the packet. >> >>>> >> >>>> The address is defined the same as for Source Address. >> >>>> >> >>>> Template ID: ### Field Type: ### Size: ### >> >>>> >> >>>> 6.12.2. Modified Source Port >> >>>> >> >>>> This information element contains the source port of the flow as >> >>>> transmitted by the exporter after a middlebox, OPES or >> >>> similar service >> >>>> was applied to the packet. It may be different than the source >> port >> >>>> information element, which contains the original source port >> >>> of the packet. >> >>>> >> >>>> Template ID: ### Field Type: ### Size: ### >> >>>> >> >>>> 6.12.3. Modified Destination Address >> >>>> >> >>>> This information element contains the destination address >> >of the flow >> >>>> as transmitted by the exporter after a middlebox, OPES >or similar >> >> >>>> service was applied to the packet. It might be >different than the >> >> >>>> destination address information element, which contains >> >the original >> >>>> destination address of the packet. >> >>>> >> >>>> Template ID: ### Field Type: ### Size: ### >> >>>> >> > >> > >> > > ------_=_NextPart_001_01C1E4A1.ADD14448 Content-Type: text/html; charset="iso-8859-1" RE: [ipfix-data] Data doc - Section 7.11

Hello Paul,

correct. SHOULD or MAY could be used in the text.

thanks,

Reinaldo

>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com]
>Sent: Monday, April 15, 2002 8:41 AM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: Juergen Quittek; Norseth, KC; ipfix-data@net.doit.wisc.edu
>Subject: Re: [ipfix-data] Data doc - Section 7.11
>
>
>Reinaldo Penno wrote:
>>
>> My concern with the "virtual" wording is that there is nothing
>> "virtual" about the modified packet. Virtual implies the
>> original/actual packet is more real than the modified one, which is
>> not. The modified packet can actually be more "real" if you are doing
>> NAT, for instance. My opinion is that another terminology sould be
>> used.
>>
>> As for the first question, imagine you receive a packet and you apply
>> several services to it (NAT, insertion of content, whatever) and you
>> want to report that (the services applied) on flow records.
>>
>> So, the order in which you apply these services matters and so the
>> order in which you report them. As I said, if you apply NAT and then
>> some firewall (possibly dropping the packet), but on the flow records
>> you say the other way around, you will get the wrong picture. This is
>> a easy example, but you can expand that for all other services that
>> modify, drop, tunnel a packet.
>
>       If you are saying that if more than one of these fields
>       are reported in a flow then they must be in order,that
>       seems reasonable to me too. But we are NOT saying you must
>       report the fields in the first place, correct?
>
>>
>> regards,
>>
>> Reinaldo
>>
>> >-----Original Message-----
>> >From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>> >Sent: Friday, April 12, 2002 6:42 PM
>> >To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC;
>> >calato@riverstonenet.com
>> >Cc: ipfix-data@net.doit.wisc.edu
>> >Subject: RE: [ipfix-data] Data doc - Section 7.11
>> >
>> >
>> >Hi Reinaldo,
>> >
>> >With 'reflect the order of the operstions performed', do you mean
>> >finding out what is the original and what the modified header field?
>> >
>> >I had a long discussion on the modified scheme versus the modified
>> >scheme with Paul:
>> >
>> >The virtual scheme:
>> >  Any source-related header field in an arriving packet is called
>> >  actual. Any destination-reated header field in a leaving packet
>> >  is called actual. Actual values are the ones usually reported.
>> >
>> >  If the value of a source-related header field in a leaving packet
>> >  differs from its value in the arriving packet, then this value is
>> >  called 'virtual'. If the value of a destination-related header
>> >  field in an arriving packet differs from its value in the leaving
>> >  packet, then this value is called 'virtual'.
>> >
>> >The modified scheme:
>> >  The value of a header field in an arriving packet is called
>> original.
>> >  Original values are the ones usually reported.
>> >  If the value of a header field is modified in the leaving packet,
>> >  then it may be reported as the 'modified' value.
>> >
>> >In the end we preferred the virtual scheme. But please feel free
>> >to convince us that the modified scheme is more appropriate.
>> >
>> >    Juergen
>> >
>> >
>> >--On 12 April 2002 11:45 -0700 Reinaldo Penno
>> ><reinaldo_penno@nortelnetworks.com> wrote:
>> >
>> >>
>> >> Hello Juergen,
>> >>
>> >> thanks for the comments. answers inline
>> >>
>> >>> -----Original Message-----
>> >>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>> >>> Sent: Friday, April 12, 2002 4:30 AM
>> >>> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC;
>> >>> calato@riverstonenet.com
>> >>> Cc: ipfix-data@net.doit.wisc.edu
>> >>> Subject: Re: [ipfix-data] Data doc - Section 7.11
>> >>>
>> >>>
>> >>> Hi Reinaldo,
>> >>>
>> >>> --On 09 April 2002 14:49 -0700 Reinaldo Penno
>> >>> <reinaldo_penno@nortelnetworks.com> wrote:
>> >>>
>> >>>>
>> >>>> In the data doc there was a part that Paul disagrees (or
>> >>> used to) with me. I'm okay with finding other names anyway,
>> >>> but IMO the description is better this way
>> >>>>
>> >>>> Basically I wanted to change section on NAT/source
>> >>> virtual/destination virtual to:
>> >>>>
>> >>>> 7.11. Middlebox and other Services
>> >>>
>> >>> Having to choose between "Virtual Information" and "Middlebox and
>> >>> other Services", I prefer the first one, because it is as general
>> >>> as "other services" and it better reflects a meter's
>view: It does
>>
>> >>> not care that much about functions and applications/services
>> running
>> >>> additionally on the same box, it just cares about what such
>> >>> applications do with packets or beterr with packet headers. Then
>> >>> the concept of virtual and actual values of header fields seem so
>> >>> be an adequate and sufficient view of what is happening.
>> >>
>> >> no problem, I can change the name. Do you think the
>> >description is adequate?
>> >>
>> >>>>
>> >>>> An exporter may be involved in providing services that require
>> >>>> application level intelligence and/or transform or filter
>> >>> content such
>> >>>
>> >>> I don't think there will be any router or other exporter device
>> >>> that deserves the attribute 'intelligent'. These boxes are SO
>> dumb!
>> >>> Just work with them and you'll see :-)
>> >>
>> >> he!he! Some of them are a little more 'intelligent'..
>> >>
>> >>>
>> >>>> as middlebox and OPES respectively.
>> >>>>
>> >>>> When the exporter is involved on these types of services
>> >the order of
>> >>>> the IEs that contain information associated with these service
>> MUST
>> >>>> reflect the order of the operations performed.
>> >>>
>> >>> No. We should not have a MUST here. This would mean that you
>> >>> cannot add middlebox functions to your box without updating the
>> >>> IPFIX software/hardware. You could not run the same
>implementation
>>
>> >>> on boxes with different functionality. It is nice if the IPFIX
>> >>> device reflects middlebox functions, but a MAY should be
>> >>> appropriate.
>> >>
>> >> What I meant by the above phrase is that the order on which
>> >these services are applied are very important ans o should be
>> >the reporting. If you apply NAT and then layer 2/3 tunneling
>> >is different than the other way around. If the exporter does not
>> >> indicate this, you might get misleading data in the end.
>> >>
>> >> So, my point was if you are ptoviding these service you
>> >SHOULD be able to report them on the order they were applied.
>> >I think that's reasonable.
>> >>
>> >>>
>> >>>>
>> >>>> Each type field of the following IEs contain the type of
>> operation
>> >>>> performed on the packet. The currently available types are:
>> >>>>
>> >>>> 1. - NAT
>> >>>> 2. - LSNAT
>> >>>> 3. - Twice NAT
>> >>>> 4. - Request Routing [KRR]
>> >>>> 5. - Outgoing L3 Tunnel
>> >>>> 6. - Incoming L3 Tunnel
>> >>>> 7. - Outgoing L2 Tunnel
>> >>>> 8. - Incoming L2 Tunnel
>> >>>> 9. - OPES (several sub-services here)
>> >>>> 10. - others...
>> >>>>
>> >>>> 6.12.1.  Modified Source Address
>> >>>>
>> >>>> This information element contains the source address of the flow
>> as
>> >>>> transmitted by the Exporter after a middlebox, OPES or
>> >>> similar service
>> >>>
>> >>> What is a OPES similar service? This is rather unclear,
>> particularly
>> >>> if you request a MUST to support it. I prefer Paul's term
>> >'redirecting
>> >>> packets/flows'.
>> >>>
>> >>>    Juergen
>> >>>
>> >>>> was applied to the packet. It may be different than the
>> >>> source address
>> >>>> information element, which contains the original source
>> >>> address of the packet.
>> >>>>
>> >>>> The address is defined the same as for Source Address.
>> >>>>
>> >>>> Template ID: ###   Field Type: ###   Size: ###
>> >>>>
>> >>>> 6.12.2.  Modified Source Port
>> >>>>
>> >>>> This information element contains the source port of the flow as
>> >>>> transmitted by the exporter after a middlebox, OPES or
>> >>> similar service
>> >>>> was applied to the packet. It may be different than the source
>> port
>> >>>> information element, which contains the original source port
>> >>> of the packet.
>> >>>>
>> >>>> Template ID: ###   Field Type: ###   Size: ###
>> >>>>
>> >>>> 6.12.3.  Modified Destination Address
>> >>>>
>> >>>> This information element contains the destination address
>> >of the flow
>> >>>> as transmitted by the exporter after a middlebox, OPES
>or similar
>>
>> >>>> service was applied to the packet. It might be
>different than the
>>
>> >>>> destination address information element, which contains
>> >the original
>> >>>> destination address of the packet.
>> >>>>
>> >>>> Template ID: ###   Field Type: ###   Size: ###
>> >>>>
>> >
>> >
>> >
>

------_=_NextPart_001_01C1E4A1.ADD14448-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Apr 15 18:06:15 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07823 for ; Mon, 15 Apr 2002 18:06:15 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16xEKz-0006H6-00 for ipfix-list@mil.doit.wisc.edu; Mon, 15 Apr 2002 16:48:37 -0500 Received: from c001-h007.c001.snv.cp.net ([209.228.32.121] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16xEKw-0006Gf-00 for ipfix@net.doit.wisc.edu; Mon, 15 Apr 2002 16:48:34 -0500 Received: (cpmta 646 invoked from network); 15 Apr 2002 14:48:02 -0700 Received: from 24.221.253.53 (HELO kcn) by smtp.register-admin.com (209.228.32.121) with SMTP; 15 Apr 2002 14:48:02 -0700 X-Sent: 15 Apr 2002 21:48:02 GMT Message-ID: <00dd01c1e4c7$6d1e6d60$850f880a@kcn> From: "K.C. Norseth" To: Subject: [ipfix] draft-ietf-ipfix-architecture-01.txt Date: Mon, 15 Apr 2002 15:49:31 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello folks, While waiting for the draft to come out more officailly, here is version 1 of the architecture draft. http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-01.txt K.C. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Apr 16 03:54:32 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25932 for ; Tue, 16 Apr 2002 03:54:26 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16xNVT-0002tv-00 for ipfix-list@mil.doit.wisc.edu; Tue, 16 Apr 2002 02:36:03 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16xNVP-0002tE-00 for ipfix-data@net.doit.wisc.edu; Tue, 16 Apr 2002 02:35:59 -0500 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g3G7ZS883959; Tue, 16 Apr 2002 09:35:28 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA15059; Tue, 16 Apr 2002 09:34:31 +0200 Date: Tue, 16 Apr 2002 09:38:41 +0200 From: Juergen Quittek To: Reinaldo Penno , "Norseth, KC" , calato@riverstonenet.com cc: ipfix-data@net.doit.wisc.edu Subject: RE: [ipfix-data] Data doc - Section 7.11 Message-ID: <1895775.1018949921@[192.168.102.164]> In-Reply-To: <7B802811BE77D51189910002A55CFD2C01E6BB30@zsc3c032.us.nortel.com> References: <7B802811BE77D51189910002A55CFD2C01E6BB30@zsc3c032.us.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo, --On 15 April 2002 10:04 -0700 Reinaldo Penno wrote: > > Juergen, > > if it's the packet, the src/dest address or whatever the argument > remains. I think it's fair to say that "virtual" is not the best > terminology to be used. I'm sure we can find a better term. As I said > it implies that the original > packet/header/field/whatever is more real (whatever this means) than > the original/actual. Well, it is more real in some way. As in the example I gave you with a NAT replacing the original source address by its own one it might be quite intuitive to call this destination address virtual. But I see your point. The semantics of 'original' value and 'modified' value of a header field changed at the observation point is much more clear and potentially easier to reason about than the concept of 'virtual' value and 'actual' value of a header field. I had been arguing pro original/modified and contra actual/vritual for along time with Paul until he convinced me, but I still see good reasons for both alternatives. Are there others than Reinaldo, Paul and me having an opinion on what concept we should prefer for the IPFIX info model? Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > Not to mention that in cases where you have twice/bi-directional NAT > this can be a source of confusion. > > thanks, > > Reinaldo > >> -----Original Message----- >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> Sent: Monday, April 15, 2002 9:55 AM >> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; >> calato@riverstonenet.com >> Cc: ipfix-data@net.doit.wisc.edu >> Subject: RE: [ipfix-data] Data doc - Section 7.11 >> >> >> Reinaldo, >> >> --On 12 April 2002 23:05 -0700 Reinaldo Penno wrote: >> >>> >>> My concern with the "virtual" wording is that there is nothing >>> "virtual" about the modified packet. Virtual implies the >>> original/actual packet is more real than the modified one, >> >> Not the packet is virtual, but the header entry for source >> or destination addresses may be virtual. If a NAT replaces >> the source address by its own one while forwarding a packet, >> then I think it is acceptable calling the modified source >> address field in the leaving packet 'virtual'. >> >> Juergen >> >>> which is not. The modified packet can actually be more "real" >>> if you are >>> doing NAT, for instance. My opinion is that another >> terminology sould be used. >>> >>> As for the first question, imagine you receive a packet and >> you apply several services to it (NAT, insertion of content, >> whatever) and you want to report that (the services applied) >> on flow records. >>> >>> So, the order in which you apply these services matters and >> so the order in which you report them. As I said, if you apply >> NAT and then some firewall (possibly dropping the packet), but >> on the flow records you say the other way around, you will get the >>> wrong picture. This is a easy example, but you can expand >> that for all other services that modify, drop, tunnel a packet. >>> >>> regards, >>> >>> Reinaldo >>> >>>> -----Original Message----- >>>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >>>> Sent: Friday, April 12, 2002 6:42 PM >>>> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; >>>> calato@riverstonenet.com >>>> Cc: ipfix-data@net.doit.wisc.edu >>>> Subject: RE: [ipfix-data] Data doc - Section 7.11 >>>> >>>> >>>> Hi Reinaldo, >>>> >>>> With 'reflect the order of the operstions performed', do you mean >>>> finding out what is the original and what the modified header field? >>>> >>>> I had a long discussion on the modified scheme versus the modified >>>> scheme with Paul: >>>> >>>> The virtual scheme: >>>> Any source-related header field in an arriving packet is called >>>> actual. Any destination-reated header field in a leaving packet >>>> is called actual. Actual values are the ones usually reported. >>>> >>>> If the value of a source-related header field in a leaving packet >>>> differs from its value in the arriving packet, then this value is >>>> called 'virtual'. If the value of a destination-related header >>>> field in an arriving packet differs from its value in the leaving >>>> packet, then this value is called 'virtual'. >>>> >>>> The modified scheme: >>>> The value of a header field in an arriving packet is >> called original. >>>> Original values are the ones usually reported. >>>> If the value of a header field is modified in the leaving packet, >>>> then it may be reported as the 'modified' value. >>>> >>>> In the end we preferred the virtual scheme. But please feel free >>>> to convince us that the modified scheme is more appropriate. >>>> >>>> Juergen >>>> >>>> >>>> --On 12 April 2002 11:45 -0700 Reinaldo Penno >>>> wrote: >>>> >>>>> >>>>> Hello Juergen, >>>>> >>>>> thanks for the comments. answers inline >>>>> >>>>>> -----Original Message----- >>>>>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >>>>>> Sent: Friday, April 12, 2002 4:30 AM >>>>>> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC; >>>>>> calato@riverstonenet.com >>>>>> Cc: ipfix-data@net.doit.wisc.edu >>>>>> Subject: Re: [ipfix-data] Data doc - Section 7.11 >>>>>> >>>>>> >>>>>> Hi Reinaldo, >>>>>> >>>>>> --On 09 April 2002 14:49 -0700 Reinaldo Penno >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> In the data doc there was a part that Paul disagrees (or >>>>>> used to) with me. I'm okay with finding other names anyway, >>>>>> but IMO the description is better this way >>>>>>> >>>>>>> Basically I wanted to change section on NAT/source >>>>>> virtual/destination virtual to: >>>>>>> >>>>>>> 7.11. Middlebox and other Services >>>>>> >>>>>> Having to choose between "Virtual Information" and "Middlebox and >>>>>> other Services", I prefer the first one, because it is as general >>>>>> as "other services" and it better reflects a meter's view: It does >>>>>> not care that much about functions and >> applications/services running >>>>>> additionally on the same box, it just cares about what such >>>>>> applications do with packets or beterr with packet headers. Then >>>>>> the concept of virtual and actual values of header fields seem so >>>>>> be an adequate and sufficient view of what is happening. >>>>> >>>>> no problem, I can change the name. Do you think the >>>> description is adequate? >>>>> >>>>>>> >>>>>>> An exporter may be involved in providing services that require >>>>>>> application level intelligence and/or transform or filter >>>>>> content such >>>>>> >>>>>> I don't think there will be any router or other exporter device >>>>>> that deserves the attribute 'intelligent'. These boxes >> are SO dumb! >>>>>> Just work with them and you'll see :-) >>>>> >>>>> he!he! Some of them are a little more 'intelligent'.. >>>>> >>>>>> >>>>>>> as middlebox and OPES respectively. >>>>>>> >>>>>>> When the exporter is involved on these types of services >>>> the order of >>>>>>> the IEs that contain information associated with these >> service MUST >>>>>>> reflect the order of the operations performed. >>>>>> >>>>>> No. We should not have a MUST here. This would mean that you >>>>>> cannot add middlebox functions to your box without updating the >>>>>> IPFIX software/hardware. You could not run the same implementation >>>>>> on boxes with different functionality. It is nice if the IPFIX >>>>>> device reflects middlebox functions, but a MAY should be >>>>>> appropriate. >>>>> >>>>> What I meant by the above phrase is that the order on which >>>> these services are applied are very important ans o should be >>>> the reporting. If you apply NAT and then layer 2/3 tunneling >>>> is different than the other way around. If the exporter does not >>>>> indicate this, you might get misleading data in the end. >>>>> >>>>> So, my point was if you are ptoviding these service you >>>> SHOULD be able to report them on the order they were applied. >>>> I think that's reasonable. >>>>> >>>>>> >>>>>>> >>>>>>> Each type field of the following IEs contain the type of >> operation >>>>>>> performed on the packet. The currently available types are: >>>>>>> >>>>>>> 1. - NAT >>>>>>> 2. - LSNAT >>>>>>> 3. - Twice NAT >>>>>>> 4. - Request Routing [KRR] >>>>>>> 5. - Outgoing L3 Tunnel >>>>>>> 6. - Incoming L3 Tunnel >>>>>>> 7. - Outgoing L2 Tunnel >>>>>>> 8. - Incoming L2 Tunnel >>>>>>> 9. - OPES (several sub-services here) >>>>>>> 10. - others... >>>>>>> >>>>>>> 6.12.1. Modified Source Address >>>>>>> >>>>>>> This information element contains the source address of >> the flow as >>>>>>> transmitted by the Exporter after a middlebox, OPES or >>>>>> similar service >>>>>> >>>>>> What is a OPES similar service? This is rather unclear, >> particularly >>>>>> if you request a MUST to support it. I prefer Paul's term >>>> 'redirecting >>>>>> packets/flows'. >>>>>> >>>>>> Juergen >>>>>> >>>>>>> was applied to the packet. It may be different than the >>>>>> source address >>>>>>> information element, which contains the original source >>>>>> address of the packet. >>>>>>> >>>>>>> The address is defined the same as for Source Address. >>>>>>> >>>>>>> Template ID: ### Field Type: ### Size: ### >>>>>>> >>>>>>> 6.12.2. Modified Source Port >>>>>>> >>>>>>> This information element contains the source port of the flow as >>>>>>> transmitted by the exporter after a middlebox, OPES or >>>>>> similar service >>>>>>> was applied to the packet. It may be different than the >> source port >>>>>>> information element, which contains the original source port >>>>>> of the packet. >>>>>>> >>>>>>> Template ID: ### Field Type: ### Size: ### >>>>>>> >>>>>>> 6.12.3. Modified Destination Address >>>>>>> >>>>>>> This information element contains the destination address >>>> of the flow >>>>>>> as transmitted by the exporter after a middlebox, OPES or similar >>>>>>> service was applied to the packet. It might be different than the >>>>>>> destination address information element, which contains >>>> the original >>>>>>> destination address of the packet. >>>>>>> >>>>>>> Template ID: ### Field Type: ### Size: ### >>>>>>> >>>> >>>> >> >> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Apr 16 13:18:10 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21782 for ; Tue, 16 Apr 2002 13:18:09 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16xVvT-0001EP-00 for ipfix-list@mil.doit.wisc.edu; Tue, 16 Apr 2002 11:35:27 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.us.nortel.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16xVvP-0001DN-00 for ipfix-app@net.doit.wisc.edu; Tue, 16 Apr 2002 11:35:23 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GGYw716490 for ; Tue, 16 Apr 2002 09:34:58 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXM0DBH>; Tue, 16 Apr 2002 09:34:49 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C01EFC748@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: ipfix-app@net.doit.wisc.edu Subject: [ipfix-app] Applicability doc revision Date: Tue, 16 Apr 2002 09:34:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1E564.9D062340" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1E564.9D062340 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E564.9D062340" ------_=_NextPart_001_01C1E564.9D062340 Content-Type: text/plain; charset="iso-8859-1" Hello Tanja, here it goes my comments on the applicability doc. sorry for using word but I is better for revision tags. I can send a PDF if you prefer. regards, Reinaldo ------_=_NextPart_001_01C1E564.9D062340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Applicability doc revision

Hello Tanja,

here it goes my comments on the applicability doc. = sorry for using word but I is better for revision tags. I can send a = PDF if you prefer.

regards,

Reinaldo

  ------_=_NextPart_001_01C1E564.9D062340-- ------_=_NextPart_000_01C1E564.9D062340 Content-Type: application/msword; name="ipfix-applicability-v1-revision1.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfix-applicability-v1-revision1.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAArwAAAAAAAAAA EAAAsQAAAAEAAAD+////AAAAAK0AAACuAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEATSAJBAAA8BK/AAAAAAAAEAAAAAAABAAA14AAAA4AYmpiauI94j0AAAAAAAAAAAAAAAAAAAAA AAAJBBYAItAAAIBXAACAVwAA13wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAACwBAAAAAAAALAEAACwB AAAAAAAALAEAAAAAAAAsAQAAAAAAACwBAAAAAAAALAEAABQAAAAAAAAAAAAAAEABAAAAAAAAPkUA AAAAAAA+RQAAAAAAAD5FAAAAAAAAPkUAABwAAABaRQAA/AAAAEABAAAAAAAAIWIAAHwBAABiRgAA AAAAAGJGAAAAAAAAYkYAAAAAAABiRgAAAAAAAGJGAAAAAAAAYkYAAAAAAABiRgAAAAAAAGJGAAAA AAAAhmEAAAIAAACIYQAAAAAAAIhhAAAAAAAAiGEAAAAAAACIYQAAAAAAAIhhAAAAAAAAiGEAACQA AACdYwAAIAIAAL1lAABeAAAArGEAABUAAAAAAAAAAAAAAAAAAAAAAAAALAEAAAAAAABiRgAAAAAA AAAAAAAAAAAAAAAAAAAAAABiRgAAAAAAAGJGAAAAAAAAYkYAAAAAAABiRgAAAAAAAKxhAAAAAAAA nloAAAAAAAAsAQAAAAAAACwBAAAAAAAAYkYAAAAAAAAAAAAAAAAAAGJGAAAAAAAAwWEAACQAAACe WgAAAAAAAJ5aAAAAAAAAnloAAAAAAABiRgAAJgUAACwBAAAAAAAAYkYAAAAAAAAsAQAAAAAAAGJG AAAAAAAAhmEAAAAAAAAAAAAAAAAAAJ5aAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAYkYAAAAAAACGYQAAAAAAAJ5aAADoBgAAnloAAAAAAAAAAAAA AAAAAIZhAAAAAAAALAEAAAAAAAAsAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhmEAAAAAAABiRgAAAAAAAFZGAAAMAAAAYGqW3GTl wQFAAQAA/kMAAD5FAAAAAAAAiEsAABYPAACGYQAAAAAAAAAAAAAAAAAAhmEAAAAAAADlYQAAPAAA ACFiAAAAAAAAhmEAAAAAAAAbZgAAAAAAAJ5aAAAAAAAAG2YAAAAAAACGYQAAAAAAAJ5aAAAAAAAA QAEAAAAAAABAAQAAAAAAACwBAAAAAAAALAEAAAAAAAAsAQAAAAAAACwBAAAAAAAAAgDZAAAASW50 ZXJuZXQgRHJhZnQJCQkJCVQuWnNlYnkNZHJhZnQtenNlYnktaXBmaXgtYXBwbGljYWJpbGl0eS0w MC50eHQJCUZoSSBGT0tVUw1FeHBpcmVzOiBBdWd1c3QgMjAwMgkJCQlSLiBQZW5ubw1WRVJTSU9O IERBVEUgRmVicnVhcnkgMjEsIDIwMDIJCQlOb3J0ZWwgTmV0d29ya3MgDUZlYnJ1YXJ5IDIwMDIN DQ0JCQlJUEZJWCBBcHBsaWNhYmlsaXR5DQ0NU3RhdHVzIG9mIHRoaXMgTWVtbw0NVGhpcyBkb2N1 bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRo IA1hbGwgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDEwIG9mIFJGQzIwMjYgWzFdLiANDUludGVybmV0 LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5n IA1UYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiBO b3RlIHRoYXQgDW90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1l bnRzIGFzIEludGVybmV0LQ1EcmFmdHMuIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1l bnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2YgDXNpeCBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVk LCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIA1kb2N1bWVudHMgYXQgYW55IHRpbWUu IEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LSBEcmFmdHMgDWFzIHJlZmVyZW5j ZSBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiANcHJvZ3Jl c3MuIiANDVRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3Nl ZCBhdCANaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0ICAgDVRoZSBs aXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQg YXQgDWh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQ0NQWJzdHJhY3QNDVRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIGhvdyB2YXJpb3VzIGFwcGxpY2F0aW9ucyBjYW4gdXNlIHRoZSBJUCAN RmxvdyBJbmZvcm1hdGlvbiBFeHBvcnQgKElQRklYKSBwcm90b2NvbC4gSXQgZnVydGhlcm1vcmUg c2hvd3MgaG93IA10aGUgSVBGSVggZnJhbWV3b3JrIHJlbGF0ZXMgdG8gb3RoZXIgYXJjaGl0ZWN0 dXJlcyBhbmQgZnJhbWV3b3Jrcy4NDUNvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudA0N VGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJT SEFMTCBOT1QiLCANIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgICJNQVki LCBhbmQgIk9QVElPTkFMIiBpbiANdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg YXMgZGVzY3JpYmVkIGluIFJGQy0yMTE5IFsgXS4NDQ0xLiBJTlRST0RVQ1RJT04JMg0yLiBURVJN SU5PTE9HWQkzDTMuIEFQUExJQ0FUSU9OUyBPRiBJUEZJWAkzDTMuMS4gQUNDT1VOVElORyBXSVRI IElQRklYCTMNMy4yLiBUUkFGRklDIFBST0ZJTElORyBXSVRIIElQRklYCTMNMy4zLiBUUkFGRklD IEVOR0lORUVSSU5HIFdJVEggSVBGSVgJMw0zLjQuIElOVFJVU0lPTiBERVRFQ1RJT04gV0lUSCBJ UEZJWAkzDTMuNS4gUU9TIE1PTklUT1JJTkcgV0lUSCBJUEZJWAkzDTMuNS4xLiBNZWFzdXJlbWVu dCBvZiBSb3VuZC10cmlwLXRpbWUgKFJUVCkgd2l0aCBJUEZJWAk0DTMuNS4yLiBNZWFzdXJlbWVu dCBvZiBPbmUtd2F5LWRlbGF5IChPV0QpIHdpdGggSVBGSVgJNA0zLjUuMy4gTWVhc3VyZW1lbnQg b2YgTG9zcyB3aXRoIElQRklYCTUNMy41LjQuIE1lYXN1cmVtZW50IG9mIGRlbGF5IHZhcmlhdGlv biB3aXRoIElQRklYCTUNMy41LjUuIFNhbXBsaW5nIGZvciBRb1MgTW9uaXRvcmluZwk1DTMuNi4g REVQTE9ZTUVOVCBPRiBTQU1QTElORyBNRVRIT0RTIElOIElQRklYCTUNNC4gUkVMQVRJT04gT0Yg SVBGSVggVE8gT1RIRVIgRlJBTUVXT1JLUyBBTkQgUFJPVE9DT0xTCTUNNC4xLiBJUEZJWCBBTkQg QUFBCTYNNC4xLjEuIENvbm5lY3RpbmcgdmlhIGFuIEFBQSBjbGllbnQJNw00LjEuMi4gQ29ubmVj dGluZyB2aWEgYW4gQXBwbGljYXRpb24gU3BlY2lmaWMgTW9kdWxlIChBU00pIDcNNC4yLiBJUEZJ WCBBTkQgUlRGTQk4DTQuMy4gSVBGSVggQ09OU0lERVJBVElPTlMgRk9SIE1JRERMRUJPWEVTCTgN NC4zLjEuIEZpcmV3YWxsCTgNNC4zLjIuIE5ldHdvcmsgQWRkcmVzcyBUcmFuc2xhdGlvbgk5DTQu My4zLiBUcmFmZmljIENvbmRpdGlvbmVycwkxMQ00LjMuNC4gVHVubmVsaW5nCTEyDTQuMy41LiBW UE5zCTEyDTQuNC4gSVBGSVggQU5EIFJNT04JMTQNNC41LiBJUEZJWCBBTkQgSVBQTQkxNA00LjYu IElQRklYIEFORCBQU0FNUAkxNA01LiBTRUNVUklUWSBDT05TSURFUkFUSU9OCTE1DTYuIFJFRkVS RU5DRVMJMTUNNy4gQUNLTk9XTEVER0VNRU5UUwkxNg04LiBBVVRIT1InUyBBRERSRVNTRVMJMTYN OS4gRlVMTCBDT1BZUklHSFQgU1RBVEVNRU5UCTE3DQ0NDTEuIEludHJvZHVjdGlvbg0NVGhlIElQ RklYIHByb3RvY29sIGRlZmluZXMgaG93IElQIEZsb3cgaW5mb3JtYXRpb24gY2FuIGJlIGV4cG9y dGVkLiANSXQgaXMgaW50ZW5kZWQgdG8gcHJvdmlkZSBpbnB1dCBmb3IgdmFyaW91cyBhcHBsaWNh dGlvbnMuIFRoaXMgDWRvY3VtZW50IGRlc2NyaWJlcyBob3cgYXBwbGljYXRpb25zIGNhbiB1c2Ug dGhlIElQRklYIHByb3RvY29sLiANRnVydGhlcm1vcmUgdGhlIHJlbGF0aW9ucyBvZiBJUEZJWCB0 byBvdGhlciBmcmFtZXdvcmtzIGFuZCANYXJjaGl0ZWN0dXJlcyBhcmUgZGVzY3JpYmVkLg0NDTIu IFRlcm1pbm9sb2d5DQ1bbWF5YmUgbmVlZGVkIF0NDTMuIEFwcGxpY2F0aW9ucyBvZiBJUEZJWA0N My4xLiBBY2NvdW50aW5nIHdpdGggSVBGSVggDVtUT0RPIGZvciBUYW5qYV0gDQ0zLjIuIFRyYWZm aWMgUHJvZmlsaW5nIHdpdGggSVBGSVggDSANW1RPRE9dDQ0NMy4zLiBUcmFmZmljIEVuZ2luZWVy aW5nIHdpdGggSVBGSVggDQ1bVE9ET10NDQ0zLjQuIEludHJ1c2lvbiBkZXRlY3Rpb24gd2l0aCBJ UEZJWCANW1RPRE8gZm9yIFJlaW5hbGRvID9dDQ1JbnRydXNpb24gRGV0ZWN0aW9uIFN5c3RlbSAo SURTKSBtb25pdG9ycyBhbmQgY29udHJvbHMgdGhlIHNlY3VyaXR5IA1pbmNpZGVudHMgWzRdPy4g VHlwaWNhbCBJRFMgc3lzdGVtIGluY2x1ZGVzIGNvbXBvbmVudHMgbGlrZSBEYXRhIA1zb3VyY2Us IFNlbnNvciwgQW5hbHl6ZXIgRXZlbnQgY29sbGVjdG9yLCBhbmQgTWFuYWdlbWVudCBzdGF0aW9u cyBbNF0/LiBBIFNlbnNvcnMgbW9uaXRvciBuZXR3b3JrIA1hbmQgc3lzdGVtIHRyYWZmaWMgZm9y IGF0dGFja3MgYW5kIG90aGVyIHNlY3VyaXR5LXJlbGF0ZWQgZXZlbnRzLiBTZW5zb3JzIA1yZXNw b25kIHRvIGFuZCBub3RpZnkgeW91IGFib3V0IHRoZXNlIGV2ZW50cyBhcyB0aGV5IG9jY3VyLiBF dmVuIGNvbGxlY3RvcnMgYXJlIA1hIG1pZGRsZS10aWVyIGNvbXBvbmVudCByZXNwb25zaWJsZSBm b3IgdHJhbnNtaXR0aW5nIGV2ZW50cyBmcm9tIFNlbnNvcnMgdG8gdGhlIA1Db25zb2xlIGFuZCBk YXRhYmFzZS4NU2Vuc29yIA0NbW9uaXRvcnMgdGhlIGRhdGEgc291cmNlIGFuZCByYWlzZXMgdGhl IGFsYXJtIHRvIHRoZSBBbmFseXplci4gVGhlIG1hbmFnZW1lbnQgDWNvbXBvbmVudCBzZXJ2ZXMg dGhlIGZvbGxvd2luZyBwdXJwb3NlczoNXyB2aXN1YWxseSBtb25pdG9ycyBldmVudHMgKHdpdGgg YSBjb25zb2xlKQ1fIGNvbGxlY3RzIGRhdGEgZnJvbSBzZW5zb3JzICh3aXRoIG9uZSBvciBtb3Jl IGV2ZW50IGNvbGxlY3RvcnMpDV8gc3RvcmVzIGRhdGEgZnJvbSBzZW5zb3JzIChpbiBhIGRhdGFi YXNlKQ1UaGUgDQ1hbmFseXplciBjb2xsZWN0cyB2YXJpb3VzIGluY2lkZW50IGluZm9ybWF0aW9u IGFuZCByZXBvcnRzIHRoaXMgdG8gDXRoZSBtYW5hZ2VtZW50IHN0YXRpb24uDQ1XaXRoIElQRklY LCB0aGUgZXZlbnQgb2YgaW50ZXJlc3QgY2FuIGJlIGV4cG9ydGVkIGVpdGhlciBmcm9tIA1jb2xs ZWN0b3Igb3IgZnJvbSBleHBvcnRlci4gRm9yIHNtb290aCBpbnRlZ3JhdGlvbiwgaXQgd2lsbCBi ZSBiZXR0ZXIgDWZvciB0aGUgSURTIHN5c3RlbSB0byBpbnRlZ3JhdGUgd2l0aCB0aGUgY29sbGVj dG9yIHNpbmNlIHRoZSANY29sbGVjdG9yIGhhcyBhbGwgdGhlIGFnZ3JlZ2F0ZWQgaW5mb3JtYXRp b24gZnJvbSBkaWZmZXJlbnQgDW9ic2VydmF0aW9uIHBvaW50cy4gW1JQIGNvbW1lbnQ6IE5vdCBz dXJlIHRoaXMgaXMgdHJ1ZS4gV2hlbiBnZXR0aW5nIGRhdGEgZGlyZWN0bHkgZnJvbSB0aGUgZXhw b3J0ZXIsIHRoZSBzZW5zb3IgZG9lcyBub3QgbmVlZCB0byB3YWl0IGZvciBjb2xsZWN0b3IgcHJv Y2Vzc2luZyB0aW1lIG9yIGxvb2sgZm9yIHRoZSBkYXRhIGl0IG5lZWRzIHRocm91Z2ggYWxsIGF2 YWlsYWJsZSBkYXRhLl0gVGhlIElEUyBjYW4gcmVxdWVzdCB0aGUgY29sbGVjdG9yIHRvIG1vbml0 b3IgdGhlIA1ldmVudHMgb3IgSVAgZmxvdyB0aHJvdWdoIGFuIElQRklYIHRlbXBsYXRlLg0NV291 bGRuknQgdGhpcyBsYXN0IHBocmFzZSBpbXBsaWVzIGEgY29udHJvbCBjaGFubmVsIGJldHdlZW4g Y29sbGVjdG9yIGFuZCBleHBvcnRlZD8NIA1bV2hvIGNvbnRyaWJ1dGVkIHRoaXMgdGV4dCB0byB0 aGUgYXJjaGl0ZWN0dXJlIGRvYyA/XQ0NMy41LiBRb1MgTW9uaXRvcmluZyB3aXRoIElQRklYLiBJ IHdvbmRlciBpZiB3ZSBjb3VsZCBjaGFuZ2UgdGhlIHRpdGxlIG9mIHRoaXMgc2VjdGlvbiB0byBy ZWFkIFNMQSBNb25pdG9yaW5nIHdpdGggSVBmaXgsIGJ1dCBrZWVwIG1vc3Qgb2YgdGhlIHRleHQg YXMgaXMuIA0NVGhlIHBlcmZvcm1hbmNlIG9mIFFvUyBtb25pdG9yaW5nIGlzIG9uZSB0YXJnZXQg YXBwbGljYXRpb24gZm9yIHVzaW5nIA10aGUgSVBGSVggcHJvdG9jb2wuIFFvUyBtb25pdG9yaW5n IGlzIHRoZSBwYXNzaXZlIG9ic2VydmF0aW9uIG9mIHRoZSANdHJhbnNtaXNzaW9uIHF1YWxpdHkg Zm9yIHNpbmdsZSBmbG93cyBvciB0cmFmZmljIGFnZ3JlZ2F0ZXMgaW4gdGhlIA1uZXR3b3JrLiBJ dCBpcyBuZWVkZWQgZm9yIGluc3RhbmNlIGZvciB0aGUgdmFsaWRhdGlvbiBvZiBRb1MgDWd1YXJh bnRlZXMgaW4gc2VydmljZSBsZXZlbCBhZ3JlZW1lbnRzLiBTb21lIFFvUyBtZXRyaWNzIHJlcXVp cmUgdGhlIA1jb3JyZWxhdGlvbiBvZiBkYXRhIGZyb20gbXVsdGlwbGUgbWVhc3VyZW1lbnQgcG9p bnRzLiBGb3IgdGhpcyB0aGUgDWNsb2NrIG9mIHRoZSBpbnZvbHZlZCBleHBvcnRpbmcgZGV2aWNl cyBuZWVkIHRvIGJlIHN5bmNocm9uaXplZC4gDUZ1cnRoZXJtb3JlIHN1Y2ggbWVhc3VyZW1lbnRz IHdvdWxkIGJlbmVmaXQgZnJvbSBwb3N0LXByb2Nlc3NpbmcgDWZ1bmN0aW9ucyAoZS5nLiBwYWNr ZXQgSUQgZ2VuZXJhdGlvbikgYXQgdGhlIGV4cG9ydGVyIGFuZC9vciANY29sbGVjdG9yLiBUaGlz IHNlY3Rpb24gZGVzY3JpYmVzIGhvdyB0aGUgbW9uaXRvcmluZyBvZiBkaWZmZXJlbnQgDW1ldHJp Y3MgY2FuIGJlIHBlcmZvcm1lZCB3aXRoIElQRklYLiBUaGUgZm9sbG93aW5nIG1ldHJpY3MgYXJl IA1jb25zaWRlcmVkOiByb3VuZCB0cmlwIHRpbWUsIG9uZS13YXktZGVsYXksIGxvc3MgYW5kIGRl bGF5IHZhcmlhdGlvbi4NDTMuNS4xLk1lYXN1cmVtZW50IG9mIFJvdW5kLXRyaXAtdGltZSAoUlRU KSB3aXRoIElQRklYDQ1UaGUgcGFzc2l2ZSBtZWFzdXJlbWVudCBvZiByb3VuZC10cmlwLXRpbWVz IChSVFQpIGNhbiBiZSBwZXJmb3JtZWQgYnkgDXVzaW5nIHBhY2tldCBwYWlyIG1hdGNoaW5nIHRl Y2huaXF1ZXMgYXMgZGVzY3JpYmVkIGluIFtCcm93MDBdLiBGb3IgDXRoZSBtZWFzdXJlbWVudHMs IHJlcXVlc3QvcmVzcG9uc2UgcGFja2V0IHBhaXJzIGZyb20gcHJvdG9jb2xzIGxpa2UgDUROUywg SUNNUCxTTk1QIG9yIFRDUCAoc3luL3N5bi1hY2ssIGRhdGEvYWNrKSBhcmUgdXRpbGl6ZWQgdG8g DXBhc3NpdmVseSBvYnNlcnZlIHRoZSBSVFQuIEFzIGFsd2F5cyBmb3IgcGFzc2l2ZSBtZWFzdXJl bWVudHMgdGhpcyANb25seSB3b3JrcyBpZiB0aGUgcmVxdWlyZWQgdHJhZmZpYyBvZiBpbnRlcmVz dCBpcyBhY3R1YWxseSBwcmVzZW50IGluIA10aGUgbmV0d29yay4gSW4gb3JkZXIgdG8gdXNlIHRo aXMgbWVhc3VyZW1lbnQgdGVjaG5pcXVlLCB0aGUgSVBGSVggDW1ldGVyIG5lZWRzIHRvIG1lYXN1 cmUgYm90aCBkaXJlY3Rpb25zLiBBIGNsYXNzaWZpY2F0aW9uIG9mIHRoZSANcHJvdG9jb2xzIG1l bnRpb25lZCBhYm92ZSBoYXMgdG8gYmUgZG9uZS4gVGhhdCBtZWFucyBwYXJ0cyBvZiB0aGUgDXRy YW5zcG9ydCBoZWFkZXIgYXJlIHVzZWQgZm9yIHRoZSBjbGFzc2lmaWNhdGlvbi4gU2luY2UgYSAN ZGlmZmVyZW50aWF0aW9uIG9mIGZsb3dzIGluIGFjY29yZGFuY2UgdG8gdGhlIHRyYW5zcG9ydCBo ZWFkZXIgaXMgb25lIA1vZiB0aGUgcmVxdWlyZW1lbnRzIGZvciBJUEZJWCwgc3VjaCBjbGFzc2lm aWNhdGlvbiBjYW4gYmUgcGVyZm9ybWVkIA13aXRob3V0IGV4dGVuc2lvbnMuIE5ldmVydGhlbGVz cywgdGhlIG1ldGVyIG5lZWRzIHRvIHJlY29nbml6ZSANcmVxdWVzdCBhbmQgcmVzcG9uc2UgcGFj a2V0cyBmb3IgdGhlIGdpdmVuIHByb3RvY29scyBhbmQgdGhlcmVmb3JlIA1uZWVkcyB0byBsb29r IGZ1cnRoZXIgaW50byB0aGUgcGFja2V0LiBUaGlzIGlzIG5vdCByZXF1aXJlZCBmb3IgSVBGSVgg DWJ1dCBjYW4gYmUgYWNoaWV2ZWQgYnkgb3B0aW9uYWwgZXh0ZW5zaW9ucyB0byB0aGUgY2xhc3Np ZmljYXRpb24gDXByb2Nlc3MuIFRoZSBleHBvcnRpbmcgZGV2aWNlIG5lZWRzIHRvIGFzc2lnbiBh IHRpbWVzdGFtcCBmb3IgdGhlIA1hcnJpdmFsIG9mIHRoZSBwYWNrZXRzLiBUaGUgY2FsY3VsYXRp b24gb2YgdGhlIFJUVCBjYW4gYmUgZG9uZSANZGlyZWN0bHkgYXQgdGhlIGV4cG9ydGVyIG9yIGF0 IHRoZSBjb2xsZWN0b3IuIEluIHRoZSBmaXJzdCBjYXNlIElQRklYIA13b3VsZCB0cmFuc2ZlciB0 aGUgY2FsY3VsYXRlZCBSVFQgdG8gdGhlIGNvbGxlY3Rvci4gSW4gdGhlIHNlY29uZCANY2FzZSBJ UEZJWCBuZWVkcyB0byBzZW5kIHRoZSBvYnNlcnZlZCBwYWNrZXQgdHlwZXMgYW5kIHRoZSB0aW1l c3RhbXBzIA10byB0aGUgY29sbGVjdG9yLg0NMy41LjIuTWVhc3VyZW1lbnQgb2YgT25lLXdheS1k ZWxheSAoT1dEKSB3aXRoIElQRklYDQ1QYXNzaXZlIG9uZS13YXktZGVsYXkgbWVhc3VyZW1lbnRz IHJlcXVpcmUgdGhlIGNvbGxlY3Rpb24gb2YgZGF0YSBhdCANdHdvIG1lYXN1cmVtZW50IHBvaW50 cy4gSXQgaXMgcmVxdWlyZWQgdG8gcmVjb2duaXplIHBhY2tldHMgYXQgdGhlIA1zZWNvbmQgbWVh c3VyZW1lbnQgcG9pbnQgaW4gb3JkZXIgdG8gY29ycmVsYXRlIHBhY2tldCBhcnJpdmFsIGV2ZW50 cyANZnJvbSBib3RoIHBvaW50cy4gVGhpcyBjYW4gYmUgZG9uZSBmb3IgaW5zdGFuY2UgYnkgY2Fw dHVyaW5nIHBhY2tldCANaGVhZGVycyBhbmQgcGFydHMgb2YgdGhlIHBhY2tldCBhbmQgcmVjb2du aXplIHBhY2tldHMgYmFzZWQgb24gdGhpcy4gDUluIG9yZGVyIHRvIHJlZHVjZSB0aGUgYW1vdW50 IG9mIG1lYXN1cmVtZW50IGRhdGEgYSB1bmlxdWUgcGFja2V0IElEIA1jYW4gYmUgY2FsY3VsYXRl ZCBmcm9tIHRoZSBoZWFkZXIgYW5kIHBhcnQgb2YgdGhlIGNvbnRlbnQgZS5nLiBieSANdXNpbmcg YSBDUkMgb3IgaGFzaCBmdW5jdGlvbiBbR3JETTk4LCBEdUdyMDAsIFpzWkMwMV0uU2luY2UgSVBG SVggaXMgDW5vdCB0YXJnZXRlZCBhdCBwYWNrZXQgY2FwdHVyaW5nIHRoZXNlIGZ1bmN0aW9uYWxp dGllcyBkbyBub3QgbmVlZCB0byANYmUgc3VwcG9ydGVkIGJ5IGEgc3RhbmRhcmQgSVBGSVggbWV0 ZXIuIE5ldmVydGhlbGVzcywgaW4gc29tZSANc2NlbmFyaW9zIGl0IG1pZ2h0IGJlIHN1ZmZpY2ll bnQgdG8gY2FsY3VsYXRlIGEgcGFja2V0IElEIHVuZGVyIA1jb25zaWRlcmF0aW9uIG9mIGhlYWRl ciBmaWVsZHMgaW5jbHVkaW5nIGRhdGFncmFtIElEIGFuZCBtYXliZSANc2VxdWVuY2UgbnVtYmVy cyAoZnJvbSB0cmFuc3BvcnQgcHJvdG9jb2xzKSB3aXRob3V0IGxvb2tpbmcgYXQgcGFydHMgDW9m IHRoZSBwYWNrZXQgY29udGVudC4gRXNwZWNpYWxseSBpZiBwYWNrZXQgSURzIG5lZWQgdG8gYmUg dW5pcXVlIA1vbmx5IGZvciBhIGNlcnRhaW4gdGltZSBpbnRlcnZhbCBvciBhIGNlcnRhaW4gYW1v dW50IG9mIHBhY2tldCBJRCANY29sbGlzaW9ucyBpcyB0b2xlcmFibGUgdGhpcyBjYW4gYmUgYSBz b2x1dGlvbi4gDQ0zLjUuMy5NZWFzdXJlbWVudCBvZiBMb3NzIHdpdGggSVBGSVgNDVBhc3NpdmUg bG9zcyBtZWFzdXJlbWVudHMgZm9yIHNpbmdsZSBmbG93cyBjYW4gYmUgcGVyZm9ybWVkIGF0IG9u ZSANbWVhc3VyZW1lbnQgcG9pbnQgZm9yIGluc3RhbmNlIGJ5IHVzaW5nIHNlcXVlbmNlIG51bWJl cnMgdGhhdCBhcmUgDXByZXNlbnQgaW4gaGlnaGVyIGxheWVyIHByb3RvY29scy4gVGhpcyByZXF1 aXJlcyB0aGUgY2FwdHVyaW5nIG9mIHRoZSANc2VxdWVuY2UgbnVtYmVycyBvZiBzdWJzZXF1ZW50 IHBhY2tldHMgb2YgdGhlIG9ic2VydmVkIGZsb3cgYXQgdGhlIA1JUEZJWCBtZXRlci4gQW4gYWx0 ZXJuYXRpdmUgdG8gdGhpcyBpcyB0byBwZXJmb3JtIGEgdHdvLXBvaW50IA1tZWFzdXJlbWVudCBh cyBkZXNjcmliZWQgYWJvdmUgYW5kIGp1c3QgY29uc2lkZXIgcGFja2V0cyBhcyBsb3N0IHRoYXQg DWRvIG5vdCBhcnJpdmUgYXQgdGhlIHNlY29uZCBtZWFzdXJlbWVudCBwb2ludCBpbiBhIGdpdmVu IG1heGltdW0gdGltZSANZnJhbWUuIA0NMy41LjQuTWVhc3VyZW1lbnQgb2YgZGVsYXkgdmFyaWF0 aW9uIHdpdGggSVBGSVgNDURlbGF5IHZhcmlhdGlvbiBpcyBkZWZpbmVkIGFzIHRoZSBkaWZmZXJl bmNlIG9mIG9uZS13YXktZGVsYXkgdmFsdWVzIA1mb3Igc2VsZWN0ZWQgcGFja2V0cy5bRGVDaTAx XS4gVGhlcmVmb3JlIHRoaXMgbWV0cmljIGNhbiBiZSANY2FsY3VsYXRlZCBieSBwZXJmb3JtaW5n IHBhc3NpdmUgbWVhc3VyZW1lbnQgb2Ygb25lLXdheS1kZWxheSBmb3IgDXN1YnNlcXVlbnQgcGFj a2V0cyAoZS5nLiBvZiBhIGZsb3cpIGFuZCB0aGVuIGNhbGN1bGF0ZSB0aGUgDWRpZmZlcmVuY2Vz LiANDTMuNS41LlNhbXBsaW5nIGZvciBRb1MgTW9uaXRvcmluZw0NU2luY2UgUW9TIG1vbml0b3Jp bmcgY2FuIGxlYWQgdG8gYW4gb3ZlcndoZWxtaW5nIGFtb3VudCBvZiANbWVhc3VyZW1lbnQgcmVz dWx0IGRhdGEsIGl0IHdvdWxkICBoaWdobHkgYmVuZWZpdCBmcm9tIHRoZSBkZXBsb3ltZW50IA1v ZiBtZWNoYW5pc21zIHRvIHJlZHVjZSB0aGUgbWVhc3VyZW1lbnQgZGF0YSwgbGlrZSBhZ2dyZWdh dGlvbiBvZiANcmVzdWx0cyBhbmQgc2FtcGxpbmcuIFNhbXBsaW5nIG1ldGhvZHMgY2FuIGJlIGdy b3VwZWQgYWNjb3JkaW5nIHRvIA10aGUgc2FtcGxpbmcgc3RyYXRlZ3kgKHN5c3RlbWF0aWMsIHJh bmRvbSBvciBzdHJhdGlmaWVkKSBhbmQgdGhlIA10cmlnZ2VyIHRoYXQgc3RhcnRzIGEgc2FtcGxp bmcgaW50ZXJ2YWwgKGNvdW50LWJhc2VkLCB0aW1lLWJhc2VkIG9yIA1wYWNrZXQtY29udGVudC1i YXNlZCkgW0NsUEI5M10uIFNhbXBsaW5nIGNhbiBhbHNvIGJlIHVzZWQgYXMgYSBtZXRob2QgDXRv IGR5bmFtaWNhbGx5IHJlZHVjZSByZXNvdXJjZSBjb25zdW1wdGlvbiBpZiB0aGUgbWV0ZXIgaXMg DW92ZXJsb2FkZWQuIFRoZW4gdGhlIElQRklYIG1ldGVyIGNhbiBzd2l0Y2ggdG8gYSBzYW1wbGlu ZyBtZXRob2QgaWYgDXRvbyBtYW55IHBhY2tldHMgaGF2ZSB0byBiZSBvYnNlcnZlZC4gU2luY2Ug dGhlIGV4cGVjdGVkIGVzdGltYXRpb24gDWVycm9yIGRlcGVuZHMgaGVhdmlseSBvbiB0aGUgdXNl ZCBzYW1wbGluZyBzdHJhdGVneSwgdGhlIGFwcGxpY2F0aW9uIA10aGF0IHJlY2VpdmVzIHRoZSBk YXRhIG5lZWRzIHRvIGJlIGF3YXJlIG9mIHRoZSBzYW1wbGluZyBzY2hlbWUgYW5kIA10aGUgdXNl ZCBwYXJhbWV0ZXJzLiBUaGVyZWZvcmUgaXQgaXMgaW1wb3J0YW50IHRoYXQgdGhlIElQRklYIA1l eHBvcnRlciBpbmZvcm1zIHRoZSBjb2xsZWN0b3IgcHJlY2lzZWx5IGFib3V0IHRoZSB1c2VkIHNh bXBsaW5nIA1zdHJhdGVneS4gVGhpcyBpcyBldmVuIG1vcmUgcmVxdWlyZWQgaWYgdGhlIElQRklY IG1ldGVyIGR5bmFtaWNhbGx5IA1pbnZva2VzIHNhbXBsaW5nLg0NMy42LiBEZXBsb3ltZW50IG9m IFNhbXBsaW5nIE1ldGhvZHMgaW4gSVBGSVgNDVtUT0RPIGZvciBUYW5qYV0gliBJIHdvbmRlciBp ZiB0aGlzIGlzIG5lZWRlZC4gDQ0NICBbb3RoZXIgYXBwbGljYXRpb25zID9dIA0NNC4gUmVsYXRp b24gb2YgSVBGSVggdG8gb3RoZXIgZnJhbWV3b3JrcyBhbmQgcHJvdG9jb2xzIA0NDTQuMS4gSVBG SVggYW5kIEFBQSANDUFBQSBkZWZpbmVzIGEgcHJvdG9jb2wgYW5kIGFyY2hpdGVjdHVyZSBmb3Ig YXV0aGVudGljYXRpb24sIA1hdXRob3JpemF0aW9uIGFuZCBhY2NvdW50aW5nIGZvciBzZXJ2aWNl IHVzYWdlLiBUaGUgRElBTUVURVIgcHJvdG9jb2wgDWlzIHVzZWQgZm9yIEFBQSBjb21tdW5pY2F0 aW9uIGZvciBuZXR3b3JrIGFjY2VzcyBzZXJ2aWNlcyAoTW9iaWxlIElQLCANTkFTUkVRLCBhbmQg Uk9BTU9QUykuIFRoZSBBQUEgYXJjaGl0ZWN0dXJlIFtYWFgtUkZDMjkwM10gcHJvdmlkZXMgYSAN ZnJhbWV3b3JrIGZvciBleHRlbmRpbmcgdGhlIEFBQSBzdXBwb3J0IGFsc28gZm9yIG90aGVyIHNl cnZpY2VzLiANRElBTUVURVIgZGVmaW5lcyB0aGUgZXhjaGFuZ2Ugb2YgbWVzc2FnZXMgYmV0d2Vl biBBQUEgZW50aXRpZXMsIGUuZy4gDWJldHdlZW4gQUFBIGNsaWVudHMgYXQgYWNjZXNzIGRldmlj ZXMgYW5kIEFBQSBzZXJ2ZXJzIGFuZCBhbW9uZyBBQUEgDXNlcnZlcnMuIEl0IGlzIHVzZWQgYWxz byBmb3IgdGhlIHRyYW5zZmVycyBvZiBhY2NvdW50aW5nIHJlY29yZHMuIFtGb3IgDXVzYWdlLWJh c2VkIGFjY291bnRpbmcgbWVhc3VyZW1lbnQgZGF0YSBmcm9tIHRoZSBuZXR3b3JrIGlzIG5lZWRl ZCB0byANZ2VuZXJhdGUgYW4gYWNjb3VudGluZyByZWNvcmRdPz9DcnlwdGljIHBocmFzZS4gSVBG SVggcHJvdmlkZXMgYSBwcm90b2NvbCB0byBleHBvcnQgDW1lYXN1cmVtZW50IGRhdGEgZnJvbSB0 aGUgbWVhc3VyZW1lbnQgcG9pbnQgW29ic2VydmF0aW9uIHBvaW50P10gdG8gdGhlIGNvbnN1bWVy IG9mIHRoaXMgDWRhdGEgKGxpa2UgbmV0d29yayBtYW5hZ2VtZW50IGFuZCBhY2NvdW50aW5nIHN5 c3RlbXMpPz8gQmFkIHdvcmRpbmcuIEkgc3VnZ2VzdCB3ZSBhbHNvIHJld3JpdGUgdGhpcyBwaHJh c2UuIFRoZSANcHJvdmlzaW9uaW5nIG9mIGFjY291bnRpbmcgd2l0aCBJUEZJWCBjYW4gYmUgcmVh bGl6ZWQgd2l0aG91dCBhbiBBQUEgDWluZnJhc3RydWN0dXJlLiBUaGUgY29sbGVjdG9yIGNhbiBk aXJlY3RseSBmb3J3YXJkIHRoZSBtZWFzdXJlbWVudCANaW5mb3JtYXRpb24gdG8gYW4gYWNjb3Vu dGluZyBhcHBsaWNhdGlvbiBbYWNjb3VudGluZyBpcyBwYXJ0IG9mIEFBQSwgc28gaW4gYSB3ZSBh cmUgYWN0dWFsbHkgdXNpbmcgQUFBXS4gTmV2ZXJ0aGVsZXNzLCBpZiBhbiBBQUEgDWluZnJhc3Ry dWN0dXJlIGlzIGluIHBsYWNlIFtpdCBpcywganVzdCB0aGUgYWNjb3VudGluZyBwYXJ0XSwgSVBG SVggY2FuIHByb3ZpZGUgdGhlIGlucHV0IGZvciB0aGUgDWdlbmVyYXRpb24gb2YgYWNjb3VudGlu ZyByZWNvcmRzIGFuZCBzZXZlcmFsIGZlYXR1cmVzIG9mIHRoZSBBQUEgDWFyY2hpdGVjdHVyZSBj YW4gYmUgdXNlZC4gRmVhdHVyZXMgaW5jbHVkZSB0aGUgbWFwcGluZyBvZiBhIHVzZXIgSUQgDXRv IHRoZSBmbG93IGluZm9ybWF0aW9uIChieSB1c2luZyBhdXRoZW50aWNhdGlvbiBpbmZvcm1hdGlv bikgWypUaGlzKiBpcyByZWFsbHkgaW50ZXJlc3RpbmcuIFdlIHNob3VsZCBleHBhbmQgb24gdGhp cy4gQSBwYXJhZ3JhcGggb24gdXNlciBiYXNlZCBiaWxsaW5nIGFuZCBzZXJ2aWNlcyBhcyBhIGNv bnNlcXVlbmNlIG9mIEFBQS1JUEZJWCBpbnRlZ3JhdGlvbiB3b3VsZCBiZSB2ZXJ5IG5pY2VdLCB0 aGUgDWdlbmVyYXRpb24gb2YgRElBTUVURVIgYWNjb3VudGluZyByZWNvcmRzIGFuZCB0aGUgc2Vj dXJlIGV4Y2hhbmdlIG9mIA1hY2NvdW50aW5nIHJlY29yZHMgYmV0d2VlbiBkb21haW5zIHdpdGgg RElBTUVURVIuIFRocmVlIHBvc3NpYmlsaXRpZXMgDXRvIGNvbm5lY3QgSVBGSVggYW5kIEFBQSBj YW4gYmUgZGlzdGluZ3Vpc2hlZDogDQ0NDTQuMS4xLkNvbm5lY3RpbmcgdmlhIGFuIEFBQSBjbGll bnQNDU9uZSBwb3NzaWJpbGl0eSB0byBjb25uZWN0IElQRklYIGFuZCBBQUEgaXMgdG8gcnVuIGFu IEFBQSBjbGllbnQgb24gDXRoZSBJUEZJWCBjb2xsZWN0b3IuIFRoaXMgY2xpZW50IGNhbiBnZW5l cmF0ZSBESUFNRVRFUiBhY2NvdW50aW5nIA1tZXNzYWdlcyBhbmQgc2VuZCB0aGVtIHRvIGFuIEFB QSBzZXJ2ZXIuIFRoZSBtYXBwaW5nIG9mIHRoZSBmbG93IA1pbmZvcm1hdGlvbiB0byBhIHVzZXIg SUQgY2FuIGJlIGRvbmUgaW4gdGhlIEFBQSBzZXJ2ZXIgYnkgdXNpbmcgDWRhdGEgZnJvbSB0aGUg YXV0aGVudGljYXRpb24gcHJvY2Vzcy4gRElBTUVURVIgYWNjb3VudGluZyBtZXNzYWdlcyANY2Fu IGJlIHNlbnQgdG8gdGhlIGFjY291bnRpbmcgYXBwbGljYXRpb24gb3IgdG8gb3RoZXIgQUFBIHNl cnZlcnMgDShlLmcuIGluIHJvYW1pbmcgc2NlbmFyaW9zKS4NDSAgICAgICArLS0tLS0tLS0tKyAg RElBTUVURVIgICAgKy0tLS0tLS0tLSsNICAgICAgIHwgIEFBQS1TICB8LS0tLS0tLS0tLS0tLT58 ICBBQUEtUyAgfA0gICAgICAgKy0tLS0tLS0tLSsgICAgICAgICAgICAgICstLS0tLS0tLS0rDSAg ICAgICAgICAgIF4NICAgICAgICAgICAgfCBESUFNRVRFUg0gICAgICAgICAgICB8DSAgICAgICAg ICAgIHwNICAgICArLS0rLS0tLS0tLS0rLS0rDSAgICAgfCAgfCAgQUFBLUMgfCAgfA0gICAgICsg ICstLS0tLS0tLSsgIHwNICAgICB8ICAgICAgICAgICAgICB8DSAgICAgfCAgQ29sbGVjdG9yICAg fA0gICAgICstLS0tLS0tLS0tLS0tLSsgICAgDSAgICAgICAgICAgIF4NICAgICAgICAgICAgfCBJ UEZJWA0gICAgICAgICAgICB8DSAgICAgICstLS0tLS0tLS0tLS0rDSAgICAgIHwgIEV4cG9ydGVy ICB8DSAgICAgICstLS0tLS0tLS0tLS0rICAgDQ1GaWd1cmUgMjogSVBGSVggY29sbGVjdG9yIGNv bm5lY3RzIHRvIEFBQSBzZXJ2ZXIgdmlhIEFBQSBjbGllbnQgDQ0NNC4xLjIuIENvbm5lY3Rpbmcg dmlhIGFuIEFwcGxpY2F0aW9uIFNwZWNpZmljIE1vZHVsZSAoQVNNKQ0NQW5vdGhlciBwb3NzaWJp bGl0eSBpcyB0byBkaXJlY3RseSBjb25uZWN0IHRoZSBJUEZJWCBjb2xsZWN0b3Igd2l0aCANdGhl IEFBQSBzZXJ2ZXIgdmlhIGFuIGFwcGxpY2F0aW9uIHNwZWNpZmljIG1vZHVsZSAoQVNNKS4gDUFw cGxpY2F0aW9uIHNwZWNpZmljIG1vZHVsZXMgaGF2ZSBiZWVuIHByb3Bvc2VkIGJ5IHRoZSBJUlRG IEFBQSANYXJjaGl0ZWN0dXJlIHJlc2VhcmNoIGdyb3VwIChBQUFSQ0gpIGluIFtSRkMyOTAzXS4g VGhleSBhY3QgYXMgYW4gDWludGVyZmFjZSBiZXR3ZWVuIEFBQSBzZXJ2ZXIgYW5kIHNlcnZpY2Ug ZXF1aXBtZW50LiBJbiB0aGlzIGNhc2UgDXRoZSBJUEZJWCBjb2xsZWN0b3IgaXMgcGFydCBvZiB0 aGUgQVNNLiBUaGUgQVNNIGFjdHMgYXMgYW4gDWludGVyZmFjZSBiZXR3ZWVuIHRoZSBJUEZJWCBw cm90b2NvbCBhbmQgdGhlIGlucHV0IGludGVyZmFjZSBvZiB0aGUgDUFBQSBzZXJ2ZXIuIFRoZSBB U00gdHJhbnNsYXRlcyB0aGUgcmVjZWl2ZWQgSVBGSVggZGF0YSBpbnRvIGFuIA1hcHByb3ByaWF0 ZSBmb3JtYXQgZm9yIHRoZSBBQUEgc2VydmVyLiBUaGUgQUFBIHNlcnZlciB0aGVuIGNhbiBhZGQg DWluZm9ybWF0aW9uIGFib3V0IHRoZSB1c2VyIElEIGFuZCBnZW5lcmF0ZSBhIERJQU1FVEVSIGFj Y291bnRpbmcgDXJlY29yZC4gVGhpcyBhY2NvdW50aW5nIHJlY29yZCBjYW4gYmUgc2VudCB0byBh biBhY2NvdW50aW5nIA1hcHBsaWNhdGlvbiBvciB0byBvdGhlciBBQUEgc2VydmVzLiBbSSBsaWtl ZCB0aGlzIHNlY3Rpb24uLi5dDQ0NDQ0gICAgICAgKy0tLS0tLS0tLSsgIERJQU1FVEVSICAgICst LS0tLS0tLS0rDSAgICAgICB8ICBBQUEtUyAgfC0tLS0tLS0tLS0tLS0+fCAgQUFBLVMgIHwNICAg ICAgICstLS0tLS0tLS0rICAgICAgICAgICAgICArLS0tLS0tLS0tKw0gICAgICAgICAgICBeDSAg ICAgICAgICAgIHwNICAgICstLS0tLS0tLS0tLS0tLS0tLS0rDSAgICB8ICAgICBBU00gICAgICAg ICAgfA0gICAgfCAgKy0tLS0tLS0tLS0tLSsgIHwNICAgIHwgIHwgIENvbGxlY3RvciB8ICB8DSAg ICArLS0tLS0tLS0tLS0tLS0tLS0tKw0gICAgICAgICAgICBeDSAgICAgICAgICAgIHwgSVBGSVgN ICAgICAgICAgICAgfA0gICAgICArLS0tLS0tLS0tLS0tKw0gICAgICB8ICBFeHBvcnRlciAgfA0g ICAgICArLS0tLS0tLS0tLS0tKw0NRmlndXJlIDM6IElQRklYIGNvbm5lY3RzIHRvIEFBQSBzZXJ2 ZXIgdmlhIEFTTQ0NDTQuMi4gSVBGSVggYW5kIFJURk0gDVtUT0RPIGZvciBUYW5qYV0gDQ00LjMu IElQRklYIENvbnNpZGVyYXRpb25zIGZvciBNaWRkbGVib3hlcyANDUEgTWlkZGxlYm94IGlzIGEg bmV0d29yayBpbnRlcm1lZGlhdGUgZGV2aWNlIHRoYXQgaW1wbGVtZW50cyBvbmUgb3IgDW1vcmUg b2YgdGhlIG1pZGRsZWJveCBzZXJ2aWNlcy4gUG9saWN5IGJhc2VkIHBhY2tldCBmaWx0ZXJpbmcg KGEuay5hLiANZmlyZXdhbGwpLCBOZXR3b3JrIGFkZHJlc3MgdHJhbnNsYXRpb24gKE5BVCksIElu dHJ1c2lvbiBkZXRlY3Rpb24sIA1Mb2FkIGJhbGFuY2luZywgUG9saWN5IGJhc2VkIHR1bm5lbGlu ZyBhbmQgSVBzZWMgc2VjdXJpdHkgYXJlIGFsbCANZXhhbXBsZXMgb2YgYSBtaWRkbGVib3ggZnVu Y3Rpb24gKG9yIHNlcnZpY2UpLiBbTUNGV10uIEZvciBpbnN0YW5jZSwgDWEgTkFUIG1pZGRsZWJv eCBpcyBhIG1pZGRsZWJveCBpbXBsZW1lbnRpbmcgTkFUIHNlcnZpY2UgYW5kIGEgDWZpcmV3YWxs IG1pZGRsZWJveCBpcyBhIG1pZGRsZWJveCBpbXBsZW1lbnRpbmcgZmlyZXdhbGwgc2VydmljZS4g DQ1JdCBpcyBleHBlY3RlZCB0aGF0IHRoZSBleHBvcnRlciBpbiB0aGUgSVBGSVggYXJjaGl0ZWN0 dXJlIHdpbGwgDXByb2JhYmx5IGltcGxlbWVudCBzb21lIGZvcm0gb2YgbWlkZGxlYm94IHNlcnZp Y2UgZ2l2ZW4gaXRzIHViaXF1aXR5IA10b2RheS4gU2luY2Ugc29tZSBvZiB0aGVzZSBtaWRkbGVi b3ggc2VydmljZXMgbWlnaHQgYWZmZWN0IGZsb3cgDWV4cG9ydGF0aW9uIGFuZCBob3cgdGhlIGNv bGxlY3RvciBpbnRlcnByZXRzIHRoZW0sIHRoZXJlIGlzIGEgbmVlZCB0byANcHJvdmlkZSBhbiBh bmFseXNpcyBvZiB0aGVzZSBpbXBsaWNhdGlvbnMgaW4gcmVsYXRpb24gdG8gdGhlIElQRklYIA1h cmNoaXRlY3R1cmUgYW5kIGEgc2V0IG9mIHJlY29tbWVuZGF0aW9ucy4gDQ1UaGUgZm9sbG93aW5n IHNlY3Rpb25zIHByb3ZpZGUgYSBub24tZXhoYXVzdGl2ZSBhbmFseXNpcyBvZiBtaWRkbGVib3gg DXNlcnZpY2VzLCBpdHMgaW1wbGljYXRpb25zIG9uIHRoZSBJUEZJWCBhcmNoaXRlY3R1cmUgYW5k IGEgDWNvcnJlc3BvbmRpbmcgc2V0IG9mIHJlY29tbWVuZGF0aW9ucy4NDTQuMy4xLiBGaXJld2Fs bA0NRmlyZXdhbGwgaXMgYSBwb2xpY3kgYmFzZWQgcGFja2V0IGZpbHRlcmluZyBtaWRkbGVib3gg ZnVuY3Rpb24sIA10eXBpY2FsbHkgdXNlZCBmb3IgcmVzdHJpY3RpbmcgYWNjZXNzIHRvL2Zyb20g c3BlY2lmaWMgZGV2aWNlcyBhbmQgDWFwcGxpY2F0aW9ucy4gVGhlIHBvbGljaWVzIGFyZSBvZnRl biB0ZXJtZWQgQWNjZXNzIENvbnRyb2wgTGlzdHMgDShBQ0xzKVtNQ0ZXXS4gIA0NVGhlIGZpcmV3 YWxsIG1pZGRsZWJveCBzZXJ2aWNlIGFsbG93cyB0aGUgZXhwb3J0ZXIgdG8gZXhwbGljaXRseSBk cm9wIA1wYWNrZXRzIGJhc2VkIG9uIHNvbWUgYWRtaW5pc3RyYXRpdmUgcG9saWN5LiBJbiB0aGlz IGNhc2UsIHRoZSANZXhwb3J0ZXIgY2FuIHRha2Ugb25lIG9mIHRoZSBmb2xsb3dpbmcgYWN0aW9u cyB0aGF0IHdpbGwgaGF2ZSBhIA1kaXJlY3QgaW1wYWN0IG9uIHRoZSBpbmZvcm1hdGlvbiBwcm92 aWRlZCBieSB0aGUgY29sbGVjdG9yIHRvIHRoZSANdXNlci4NDSogU2lsZW50bHkgRGlzY2FyZA0N SW4gdGhpcyBjYXNlIHRoZSBwYWNrZXQgaXMgZGlzY2FyZGVkIGFuZCBubyBmbG93IGluZm9ybWF0 aW9uIHJlY29yZCANaXMgc2VudCB0byB0aGUgY29sbGVjdG9yLg0NKiBEaXNjYXJkIGFuZCBleHBv cnQgZmxvdw0NSW4gdGhpcyBjYXNlIHRoZSBwYWNrZXQgaXMgZGlzY2FyZGVkLCBhbmQgdGhlIGZs b3cgaW5mb3JtYXRpb24gcmVjb3JkIA1pcyBzZW50IHRvIHRoZSBjb2xsZWN0b3IuDQ0qIERpc2Nh cmQgYW5kIGV4cG9ydCBmbG93IHdpdGggZGlzY2FyZCBub3RpZmljYXRpb24NDUluIHRoaXMgY2Fz ZSB0aGUgcGFja2V0IGlzIGRpc2NhcmRlZCwgYW5kIHRoZSBmbG93IGluZm9ybWF0aW9uIHJlY29y ZCANaXMgc2VudCB0byB0aGUgY29sbGVjdG9yIHdpdGggYW4gaW5kaWNhdGlvbiB0aGF0IHRoZSBw YWNrZXQgd2FzIA1kaXNjYXJkZWQuDQ00LjMuMi4gTmV0d29yayBBZGRyZXNzIFRyYW5zbGF0aW9u DQ1OZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRpb24gaXMgYSBtZXRob2QgYnkgd2hpY2ggSVAgYWRk cmVzc2VzIGFyZSANbWFwcGVkIGZyb20gb25lIGFkZHJlc3MgcmVhbG0gdG8gYW5vdGhlciwgcHJv dmlkaW5nIHRyYW5zcGFyZW50IA1yb3V0aW5nIHRvIGVuZCBob3N0cy4gVHJhbnNwYXJlbnQgcm91 dGluZyBoZXJlIHJlZmVycyB0byBtb2RpZnlpbmcgDWVuZC1ub2RlIGFkZHJlc3NlcyBlbi1yb3V0 ZSBhbmQgbWFpbnRhaW5pbmcgc3RhdGUgZm9yIHRoZXNlIHVwZGF0ZXMgDXNvIHRoYXQgd2hlbiBh IGRhdGFncmFtIGxlYXZlcyBvbmUgcmVhbG0gYW5kIGVudGVycyBhbm90aGVyLCANZGF0YWdyYW1z IHBlcnRhaW5pbmcgdG8gYSBzZXNzaW9uIGFyZSBmb3J3YXJkZWQgdG8gdGhlIHJpZ2h0IGVuZC1o b3N0IA1pbiBlaXRoZXIgcmVhbG0gW05BVC1URVJNXS4gDQ0+RnJvbSBhbiBleHBvcnRlciAobWlk ZGxlYm94KSBwZXJzcGVjdGl2ZSwgYSBOQVQgaXMgY29tcG9zZWQgb2YgdHdvIA1mbG93cywgb25l IGZyb20gdGhlIGNsaWVudCB0byB0aGUgTkFUIG1pZGRsZWJveCBhbmQgYW5vdGhlciBmcm9tIHRo ZSANTkFUIG1pZGRsZWJveCB0byB0aGUgZGVzdGluYXRpb24uIEJhc2VkIG9uIHRoaXMgZmFjdCwg dGhlIGV4cG9ydGVyIA1oYXMgc2V2ZXJhbCBtb2RlcyBvZiBvcGVyYXRpb24sIGkuZS4sIGl0IGNh biBleHBvcnQgdGhlIHByaXZhdGUgcmVhbG0gDWZsb3csIHRoZSBwdWJsaWMgcmVhbG0sIG9yIGJv dGguIFRoaXMgaXMgZnVydGhlciBjb25zdHJhaW5lZCBieSB0aGUgDWZsYXZvciBvZiBOQVQgaW1w bGVtZW50ZWQsIG1lYW5pbmcgdGhhdCBpbiBvcmRlciBmb3IgdGhlIGV4cG9ydGVkIA1pbmZvcm1h dGlvbiB0byBiZSB1c2VmdWwgZm9yIHRoZSBjb2xsZWN0b3IsIHNvbWV0aW1lcyB0aGUgYXNzb2Np YXRlZCANZmxvd3Mgb24gdGhlIHR3byByZWFsbXMgbmVlZCB0byBiZSBleHBvcnRlZCBpbiB0aGUg c2FtZSBmbG93IHJlY29yZC4gDQ1BbHRob3VnaCB0aGVyZSBhcmUgbWFueSBmbGF2b3JzIG9mIGFk ZHJlc3MgdHJhbnNsYXRpb24gdGhhdCBsZW5kIA10aGVtc2VsdmVzIHRvIGRpZmZlcmVudCBhcHBs aWNhdGlvbnMsIHRoaXMgc2VjdGlvbiB3aWxsIG9ubHkgYWRkcmVzcyANdGhlIElQRklYIGFyY2hp dGVjdHVyZSBpbXBsaWNhdGlvbnMgb2YgdHJhZGl0aW9uYWwgTkFULCBiaS0NZGlyZWN0aW9uYWwg TkFUIGFuZCB0d2ljZSBOQVQuDQ00LjMuMi4xLiBUcmFkaXRpb25hbCBOQVQNDVRyYWRpdGlvbmFs IE5BVCB3b3VsZCBhbGxvdyBob3N0cyB3aXRoaW4gYSBwcml2YXRlIG5ldHdvcmsgdG8gDXRyYW5z cGFyZW50bHkgYWNjZXNzIGhvc3RzIGluIHRoZSBleHRlcm5hbCBuZXR3b3JrLCBpbiBtb3N0IGNh c2VzLiBJbiANYSB0cmFkaXRpb25hbCBOQVQsIHNlc3Npb25zIGFyZSB1bmlkaXJlY3Rpb25hbCwg b3V0Ym91bmQgZnJvbSB0aGUgDXByaXZhdGUgbmV0d29yay4gVGhpcyBpcyBpbiBjb250cmFzdCB3 aXRoIGJpLWRpcmVjdGlvbmFsIE5BVCwgd2hpY2ggDXBlcm1pdHMgc2Vzc2lvbnMgaW4gYm90aCBp bmJvdW5kIGFuZCBvdXRib3VuZCBkaXJlY3Rpb25zLiBBIGRldGFpbGVkIA1kZXNjcmlwdGlvbiBv ZiB0cmFkaXRpb25hbCBOQVQgbWF5IGJlIGZvdW5kIGluIHNlY3Rpb24gW05BVC1URVJNXS4NDUlm IHRoZSBleHBvcnRlciBpcyBwcm92aWRpbmcgdHJhZGl0aW9uYWwgTkFUIHNlcnZpY2UgYW5kIG9u bHkgdGhlIA1wcml2YXRlIHJlYWxtIGZsb3cgaXMgZXhwb3J0ZWQsIG9ubHkgZGVzdGluYXRpb24g YmFzZWQgaW5mb3JtYXRpb24gDWNhbiBiZSBpbmZlcnJlZCBmcm9tIHRoZSBjb2xsZWN0b3IuIFRo ZSByZWFzb24gZm9yIHRoaXMgaXMgdHdvZm9sZC4gDUZpcnN0LCB0aGUgY29sbGVjdG9yIHdpbGwg bm90IGJlIGFibGUgdG8gZmluZCB0aGUgcmV2ZXJzZSBmbG93ICh3aGVuIA1hcHBsaWNhYmxlKSBh c3NvY2lhdGVkIHdpdGggYSBwcml2YXRlIHJlYWxtIGZsb3cgcmVjb3JkLCBhbmQgc2Vjb25kIA1p cyB0aGF0IGluIHRoZSBtb3JlIGdlbmVyYWwgc2NlbmFyaW8gdGhlIGNvbGxlY3RvciBjYW4gYmUg Y29ubmVjdGVkIA10byBzZXZlcmFsIGV4cG9ydGVycyBwcm92aWRpbmcgTkFUIHNlcnZpY2UgYW5k IHRoZXJlIG1pZ2h0IGJlIA1vdmVybGFwcGluZyBwcml2YXRlIHJlYWxtIGFkZHJlc3NlcyBiZXR3 ZWVuIHRoZSBuZXR3b3JrcyBjb25uZWN0ZWQgdG8gDXRoZXNlIGV4cG9ydGVycy4NDUluIGEgdHJh ZGl0aW9uYWwgTkFUIHNjZW5hcmlvIHRoZSBleHBvcnRlciBTSE9VTEQgZXhwb3J0IHByaXZhdGUg YW5kIA1wdWJsaWMgcmVhbG0gaW5mb3JtYXRpb24gaW4gdGhlIHNhbWUgZmxvdyByZWNvcmQgb3Ig cHJvdmlkZSB0aGUgDWNvbGxlY3RvciB3aXRoIGEgdW5pcXVlIGtleSB0byBhc3NvY2lhdGUgdGhl IHR3byBpZiBleHBvcnRlZCBvbiANZGlmZmVyZW50IGZsb3cgcmVjb3Jkcy4NDQ00LjMuMi4yLiBC aS1EaXJlY3Rpb25hbCBOQVQNDVdpdGggYSBiaS1kaXJlY3Rpb25hbCBOQVQsIHNlc3Npb25zIGNh biBiZSBpbml0aWF0ZWQgZnJvbSBob3N0cyBpbiANdGhlIHB1YmxpYyBuZXR3b3JrIGFzIHdlbGwg YXMgdGhlIHByaXZhdGUgbmV0d29yay4gUHJpdmF0ZSBuZXR3b3JrIA1hZGRyZXNzZXMgYXJlIGJv dW5kIHRvIGdsb2JhbGx5IHVuaXF1ZSBhZGRyZXNzZXMsIHN0YXRpY2FsbHkgb3IgDWR5bmFtaWNh bGx5IGFzIGNvbm5lY3Rpb25zIGFyZSBlc3RhYmxpc2hlZCBpbiBlaXRoZXIgZGlyZWN0aW9uLiAg DURldGFpbGVkIGRlc2NyaXB0aW9uIG9mIEJpLURpcmVjdGlvbmFsIG1heSBiZSBmb3VuZCBpbiBz ZWN0aW9uIFtOQVQtDVRFUk1dLg0NNC4zLjIuMy4gVHdpY2UgTkFUDQ1Ud2ljZSBOQVQgaXMgYSB2 YXJpYXRpb24gb2YgTkFUIGluIHRoYXQgYm90aCB0aGUgc291cmNlIGFuZCANZGVzdGluYXRpb24g YWRkcmVzc2VzIGFyZSBtb2RpZmllZCBieSBOQVQgYXMgYSBkYXRhZ3JhbSBjcm9zc2VzIA1hZGRy ZXNzIHJlYWxtcy4gVGhpcyBpcyBpbiBjb250cmFzdCB0byBUcmFkaXRpb25hbC1OQVQgYW5kIEJp LQ1EaXJlY3Rpb25hbCBOQVQsIHdoZXJlIG9ubHkgb25lIG9mIHRoZSBhZGRyZXNzZXMgKGVpdGhl ciBzb3VyY2Ugb3IgDWRlc3RpbmF0aW9uKSBpcyB0cmFuc2xhdGVkLiBOb3RlLCB0aGVyZSBpcyBu byBzdWNoIHRlcm0gYXMgJ09uY2UtDU5BVCcuIERldGFpbGVkIGRlc2NyaXB0aW9uIG9mIEJpLURp cmVjdGlvbmFsIG1heSBiZSBmb3VuZCBpbiBzZWN0aW9uIA1bTkFULVRFUk1dLg0NSW4gdGhlIGNh c2Ugb2YgdHdpY2UgTkFUIHRoZSBleHBvcnRlciBNVVNUIGV4cG9ydCBwcml2YXRlIGFuZCBwdWJs aWMgDXJlYWxtIGluZm9ybWF0aW9uIGluIHRoZSBzYW1lIGZsb3cgcmVjb3JkIG9yIHByb3ZpZGUg dGhlIGNvbGxlY3RvciANd2l0aCBhIHVuaXF1ZSBrZXkgdG8gYXNzb2NpYXRlIHRoZSB0d28gaWYg ZXhwb3J0ZWQgb24gZGlmZmVyZW50IGZsb3cgDXJlY29yZHMuDQ00LjMuMy4gVHJhZmZpYyBDb25k aXRpb25lcnMNDUEgdHJhZmZpYyBjb25kaXRpb25lciBtYXkgY29udGFpbiB0aGUgZm9sbG93aW5n IGVsZW1lbnRzOiBtZXRlciwgDW1hcmtlciwgc2hhcGVyLCBhbmQgZHJvcHBlci4gIEEgdHJhZmZp YyBzdHJlYW0gaXMgc2VsZWN0ZWQgYnkgYSANY2xhc3NpZmllciwgd2hpY2ggc3RlZXJzIHRoZSBw YWNrZXRzIHRvIGEgbG9naWNhbCBpbnN0YW5jZSBvZiBhIA10cmFmZmljIGNvbmRpdGlvbmVyW0RJ RkYtQVJDSF0uDQ0+RnJvbSBhbiBJUEZJWCBhcmNoaXRlY3R1cmUgcGVyc3BlY3RpdmUgd2UgYXJl IGdvaW5nIHRvIGFkZHJlc3MgDW1hcmtpbmcsIHNoYXBpbmcgYW5kIGRyb3BwaW5nIHNlcnZpY2Vz Lg0NNC4zLjMuMS4gTWFya2luZyANRGlmZnNlcnYgcGFja2V0IG1hcmtlcnMgc2V0IHRoZSBEUyBm aWVsZCBvZiBhIHBhY2tldCB0byBhIHBhcnRpY3VsYXIgDWNvZGVwb2ludCwgYWRkaW5nIHRoZSBt YXJrZWQgcGFja2V0IHRvIGEgcGFydGljdWxhciBEUyBiZWhhdmlvciANYWdncmVnYXRlLiAgVGhl IG1hcmtlciBtYXkgYmUgY29uZmlndXJlZCB0byBtYXJrIGFsbCBwYWNrZXRzIHdoaWNoIA1hcmUg c3RlZXJlZCB0byBpdCB0byBhIHNpbmdsZSBjb2RlcG9pbnQsIG9yIG1heSBiZSBjb25maWd1cmVk IHRvIG1hcmsgDWEgcGFja2V0IHRvIG9uZSBvZiBhIHNldCBvZiBjb2RlcG9pbnRzIHVzZWQgdG8g c2VsZWN0IGEgUEhCIGluIGEgUEhCIA1ncm91cCwgYWNjb3JkaW5nIHRvIHRoZSBzdGF0ZSBvZiBh IG1ldGVyLiAgV2hlbiB0aGUgbWFya2VyIGNoYW5nZXMgDXRoZSBjb2RlcG9pbnQgaW4gYSBwYWNr ZXQgaXQgaXMgc2FpZCB0byBoYXZlICJyZS1tYXJrZWQiIHRoZSBwYWNrZXQgDVtESUZGLUFSQ0hd Lg0NPkZyb20gYW5kIElQRklYIGFyY2hpdGVjdHVyZSBwZXJzcGVjdGl2ZSwgdGhlIGV4cG9ydGVy IGNhbiB0YWtlIG9uZSBvZiANdGhlIGZvbGxvd2luZyBhY3Rpb25zIHdoZW4gaXQgbmVlZHMgdG8g cmVtYXJrIGEgcGFja2V0Lg0NKiBVbm1hcmtlZCBmbG93DQ1UaGUgZXhwb3J0ZXIgY2FuIGV4cG9y dCB0aGUgZmxvdyBiZWZvcmUgaXQgd2FzIHJlbWFya2VkLiBUaGlzIG1vZGUgb2YgDW9wZXJhdGlv biBpcyBzdHJvbmdseSBkaXNjb3VyYWdlZC4NDSogUmVtYXJrZWQgZmxvdw0NVGhlIGV4cG9ydGVy IGNhbiBleHBvcnQgdGhlIGZsb3cgYWZ0ZXIgaXQgd2FzIHJlbWFya2VkLiANDSogVW5tYXJrZWQg YW5kIHJlbWFya2VkIGZsb3cuDQ1UaGUgZXhwb3J0ZXIgY2FuIGV4cG9ydCB0aGUgZmxvdyBiZWZv cmUgYW5kIGFmdGVyIGl0IHdhcyByZW1hcmtlZCBvciANZXhwb3J0IHRoZSBmbG93IGJlZm9yZSBp dCB3YXMgcmVtYXJrZWQgYW5kIGFuIGluZGljYXRpb24gb2Ygd2hhdCB3YXMgDXRoZSBEU0NQIGFm dGVyIGl0IHdhcyByZW1hcmtlZC4gDQ00LjMuMy4yLiBTaGFwZXJzDQ1TaGFwZXJzIGRlbGF5IHNv bWUgb3IgYWxsIG9mIHRoZSBwYWNrZXRzIGluIGEgdHJhZmZpYyBzdHJlYW0gaW4gT3JkZXIgDXRv IGJyaW5nIHRoZSBzdHJlYW0gaW50byBjb21wbGlhbmNlIHdpdGggYSB0cmFmZmljIHByb2ZpbGUu ICBBIHNoYXBlciANdXN1YWxseSBoYXMgYSBmaW5pdGUtc2l6ZSBidWZmZXIsIGFuZCBwYWNrZXRz IG1heSBiZSBkaXNjYXJkZWQgaWYgDXRoZXJlIGlzIG5vdCBzdWZmaWNpZW50IGJ1ZmZlciBzcGFj ZSB0byBob2xkIHRoZSBkZWxheWVkIHBhY2tldHMuDQ1Gb3IgYW4gSVBGSVggcGVyc3BlY3RpdmUs IHNpbmNlIHRoZSBkaXNjYXJkIG9mIGEgcGFja2V0IGJ5IGEgc2hhcGVyIA1pcyBub3Qgdm9sdW50 YXJ5LCBubyBpbmRpY2F0aW9uIHNob3VsZCBiZSBzZW50IHRvIHRoZSBjb2xsZWN0b3IuIA0NNC4z LjMuMy4gRHJvcHBlcnMNDURyb3BwZXJzIGRpc2NhcmQgc29tZSBvciBhbGwgb2YgdGhlIHBhY2tl dHMgaW4gYSB0cmFmZmljIHN0cmVhbSBpbiANb3JkZXIgdG8gYnJpbmcgdGhlIHN0cmVhbSBpbnRv IGNvbXBsaWFuY2Ugd2l0aCBhIHRyYWZmaWMgcHJvZmlsZS4gDVRoaXMgcHJvY2VzcyBpcyBrbm93 biBhcyAicG9saWNpbmciIHRoZSBzdHJlYW0uICBOb3RlIHRoYXQgYSBkcm9wcGVyIA1jYW4gYmUg aW1wbGVtZW50ZWQgYXMgYSBzcGVjaWFsIGNhc2Ugb2YgYSBzaGFwZXIgYnkgc2V0dGluZyB0aGUg DXNoYXBlciBidWZmZXIgc2l6ZSB0byB6ZXJvIChvciBhIGZldykgcGFja2V0cy4NDUluIGEgbWFu bmVyIGFuYWxvZ291cyB0byB0aGUgbWlkZGxlYm94IGZpcmV3YWxsIHNlcnZpY2UsIG1pZGRsZWJv eCANcG9saWNpbmcgc2VydmljZXMgYWxzbyBhbGxvdyB0aGUgZXhwb3J0ZXIgdG8gZXhwbGljaXRs eSBkcm9wIHBhY2tldHMgDWJhc2VkIG9uIHNvbWUgYWRtaW5pc3RyYXRpdmUgcG9saWN5LiANDVRo ZSB0aHJlZSBwb3NzaWJsZSBleHBvcnQgYmVoYXZpb3JzIGRlc2NyaWJlZCBmb3IgdGhlIGZpcmV3 YWxsIA1zZXJ2aWNlIHdoZW4gYSBwYWNrZXQgbmVlZHMgdG8gYmUgZHJvcHBlZCBhcmUgYWxzbyBh cHBsaWNhYmxlIHRvIA1oZXJlLCBpLmUuLCBzaWxlbnQgZGlzY2FyZCwgZGlzY2FyZCBhbmQgZXhw b3J0IGZsb3csIGRpc2NhcmQgYW5kIA1leHBvcnQgZmxvdyB3aXRoIGRpc2NhcmQgbm90aWZpY2F0 aW9uLg0NNC4zLjQuIFR1bm5lbGluZw0NVGhlIGV4cG9ydGVyIGNhbiBleHBvcnQgdGhlIGZsb3dz IGJlZm9yZSBhbmQvb3IgYWZ0ZXIgdGhleSBnZXQgDXR1bm5lbGVkLiBJbiB0aGUgbGF0ZXIgY2Fz ZSB0aGUgZW5jYXBzdWxhdGVkIGZsb3cgaW5mb3JtYXRpb24gbWlnaHQgDW5vdCBiZSBhdmFpbGFi bGUgZHVlIHRvIGNvbmZpZGVudGlhbGl0eSBwcmVjYXV0aW9ucyBzdWNoIGFzIHRob3NlIA11c2Vk IGJ5IElQc2VjLCBvciBkdWUgdG8gdGhlIGZhY3QgdGhlIGV4cG9ydGVyIGxhY2tzIHRoZSBuZWNl c3NhcnkgDWludGVsbGlnZW5jZSB0byBpbnNwZWN0IHRoZSBlbmNhcHN1bGF0ZWQgcGFja2V0LiBN b3Jlb3ZlciwgZGVwZW5kaW5nIA1vbiB3aGVyZSBpbiB0aGUgbmV0d29yayB0aGUgZXhwb3J0ZXIg aXMgbG9jYXRlZCwgaXQgbWlnaHQgb25seSBiZSANYWJsZSB0byBleHBvcnQgZmxvd3MgYXNzb2Np YXRlZCB3aXRoIHRoZSB0dW5uZWwsIHdpdGhvdXQgdmlzaWJpbGl0eSANaW50byB0aGUgZW5jYXBz dWxhdGVkIHBhY2tldC4NDUFwYXJ0IGZyb20gd2hhdCB3YXMgc2FpZCBhYm92ZSwgaXQgc2hvdWxk IGFsc28gYmUgZmFjdG9yZWQgaW4gdGhlIGZhY3QgDXRoYXQgZmxvd3MgZXhwb3J0ZWQgYmVmb3Jl IHRoZXkgZ2V0IHR1bm5lbGVkLCB3aWxsIHByb3ZpZGUgDWluZm9ybWF0aW9uIGFib3V0IHRoZSBw cml2YXRlIG5ldHdvcmsgc2l0ZXMsIGJ1dCBub3QgbmVjZXNzYXJpbHkgDWFib3V0IHRoZSBiYWNr Ym9uZSwgc2luY2UgdGhlIHJvdXRlIHRha2VuIGJ5IHRoZSBwYWNrZXQgaXQncyBub3cga25vdyAN YXQgdGhhdCBwb2ludCBpbiB0aW1lIChhbmQgdmljZS12ZXJzYSkuDQ1UdW5uZWwgdGVybWluYXRl cyBvbiBleHBvcnRlcg0NW1RPIERPIFJlaW5hbGRvXQ0NVHVubmVsIGluaXRpYXRlcyBvbiBleHBv cnRlcg0NW1RPIERPIFJlaW5hbGRvXQ0NDUV4cG9ydGVyIGltcGxlbWVudHMgdHVubmVsIHN3aXRj aGluZw0NW1RPIERPIFJlaW5hbGRvXQ0NDQ00LjMuNS4gVlBOcw0NVGhlIHRlcm0gIlZpcnR1YWwg UHJpdmF0ZSBOZXR3b3JrIiAoVlBOKSByZWZlcnMgdG8gdGhlIGNvbW11bmljYXRpb24gDWJldHdl ZW4gYSBzZXQgb2Ygc2l0ZXMsIG1ha2luZyB1c2Ugb2YgYSBzaGFyZWQgbmV0d29yayANaW5mcmFz dHJ1Y3R1cmUuICBNdWx0aXBsZSBzaXRlcyBvZiBhIHByaXZhdGUgbmV0d29yayBtYXkgdGhlcmVm b3JlIA1jb21tdW5pY2F0ZSB2aWEgdGhlIHB1YmxpYyBpbmZyYXN0cnVjdHVyZSwgaW4gb3JkZXIg dG8gZmFjaWxpdGF0ZSB0aGUgDW9wZXJhdGlvbiBvZiB0aGUgcHJpdmF0ZSBuZXR3b3JrLiAgVGhl IGxvZ2ljYWwgc3RydWN0dXJlIG9mIHRoZSBWUE4sIA1zdWNoIGFzIGFkZHJlc3NpbmcsIHRvcG9s b2d5LCBjb25uZWN0aXZpdHksIHJlYWNoYWJpbGl0eSwgYW5kIGFjY2VzcyANY29udHJvbCwgaXMg ZXF1aXZhbGVudCB0byBwYXJ0IG9mIG9yIGFsbCBvZiBhIGNvbnZlbnRpb25hbCBwcml2YXRlIA1u ZXR3b3JrIHVzaW5nIHByaXZhdGUgZmFjaWxpdGllcyBbUkZDMjc2NF0gW1ZQTi0yNTQ3QklTXS4N DVRoZXJlIGFyZSBtdWx0aXBsZSBmbGF2b3JzIG9mIFZQTnMsIHRoZSBvbmUgd2l0aCBtb3JlIHJl bGV2YW5jZSB0byANdGhlIElQRklYIGFyY2hpdGVjdHVyZSBpcyB0aGUgUEUtYmFzZWQtVlBOLiBB IFBFLWJhc2VkIFZQTiAob3IgDVByb3ZpZGVyIEVkZ2UtYmFzZWQgVmlydHVhbCBQcml2YXRlIE5l dHdvcmspIGlzIG9uZSBpbiB3aGljaCBQRSANZGV2aWNlcyBpbiB0aGUgU1AgbmV0d29yayBwcm92 aWRlIHRoZSBWUE4uICBUaGlzIGFsbG93cyB0aGUgZXhpc3RlbmNlIA1vZiB0aGUgVlBOIHRvIGJl IGhpZGRlbiBmcm9tIHRoZSBDRSBkZXZpY2VzLCB3aGljaCBjYW4gb3BlcmF0ZSBhcyBpZiANcGFy dCBvZiBhIG5vcm1hbCBjdXN0b21lciBuZXR3b3JrLiBBIGRldGFpbGVkIGRpc2N1c3Npb24gb2Yg VlBOcyBjYW4gDWJlIGZvdW5kIGluIFtQUFZQTi1GUl0uDQ0NNC4zLjUuMS4gTGF5ZXIgMyBQRS1i YXNlZCBWUE4NDUEgbGF5ZXIgMyBQRS1iYXNlZCBWUE4gaXMgb25lIGluIHdoaWNoIHRoZSBTUCB0 YWtlcyBwYXJ0IGluIElQIGxldmVsIA1mb3J3YXJkaW5nIGJhc2VkIG9uIHRoZSBjdXN0b21lciBu ZXR3b3JrJ3MgSVAgYWRkcmVzcyBzcGFjZS4gIEluIA1nZW5lcmFsLCB0aGUgY3VzdG9tZXIgbmV0 d29yayBpcyBsaWtlbHkgdG8gbWFrZSB1c2Ugb2YgcHJpdmF0ZSBhbmQvb3IgDW5vbi11bmlxdWUg SVAgYWRkcmVzc2VzLiAgVGhpcyBpbXBsaWVzIHRoYXQgYXQgbGVhc3Qgc29tZSBkZXZpY2VzIGlu IA10aGUgcHJvdmlkZXIgbmV0d29yayBuZWVkcyB0byB1bmRlcnN0YW5kIHRoZSBJUCBhZGRyZXNz IHNwYWNlIGFzIHVzZWQgDWluIHRoZSBjdXN0b21lciBuZXR3b3JrLiAgVHlwaWNhbGx5IHRoaXMg a25vd2xlZGdlIGlzIGxpbWl0ZWQgdG8gdGhlIA1QRSBkZXZpY2UgW1BQVlBOLUZSXSB3aGljaCBp cyBkaXJlY3RseSBhdHRhY2hlZCB0byB0aGUgY3VzdG9tZXIuDQ1JbiBhIGxheWVyIDMgUEUtYmFz ZWQgVlBOIHRoZSBwcm92aWRlciB3aWxsIG5lZWQgdG8gcGFydGljaXBhdGUgaW4gDXNvbWUgYXNw ZWN0cyBvZiBtYW5hZ2VtZW50IGFuZCBwcm92aXNpb25pbmcgb2YgdGhlIFZQTnMsIHN1Y2ggYXMg DWVuc3VyaW5nIHRoYXQgdGhlIFBFIGRldmljZXMgYXJlIGNvbmZpZ3VyZWQgdG8gc3VwcG9ydCB0 aGUgY29ycmVjdCANVlBOcy4gIFRoaXMgaW1wbGllcyB0aGF0IGxheWVyIDMgUEUtYmFzZWQgVlBO cyBhcmUgYnkgZGVmaW5pdGlvbiANcHJvdmlkZXIgcHJvdmlzaW9uZWQgVlBOcyBbUFBWUE4tRlJd Lg0NSW4gb3JkZXIgdG8gY29ubmVjdCB0aGUgZGlmZmVyZW50IFZQTiBzaXRlcyBiZWxvbmdpbmcg dG8gdGhlIHNhbWUgVlBOIA10aGUgU1AgdXNlcyBhIHR1bm5lbGluZyB0ZWNobmlxdWUgc3VjaCBh cyBNUExTLCBMMlRQIG9yIElQc2VjLiBUaGVzZSANdHVubmVscyBvcmlnaW5hdGUgYW5kIHRlcm1p bmF0ZSBvbiBQRSBkZXZpY2VzLiANDU9uZSBvZiB0aGUgY2hhcmFjdGVyaXN0aWNzIG9mIGEgbGF5 ZXIgMyBQRS1iYXNlZCBWUE5zIGlzIHRoYXQgdGhleSANb2ZmbG9hZCBzb21lIGFzcGVjdHMgb2Yg VlBOIG1hbmFnZW1lbnQgZnJvbSB0aGUgY3VzdG9tZXIgbmV0d29yay4gDT5Gcm9tIGFuIElQRklY IGFyY2hpdGVjdHVyZSBwZXJzcGVjdGl2ZSwgdGhpcyBtZWFucyB0aGF0IHRoZSBTUCBpcyB0aGUg DW9uZSB0aGF0IHBvdGVudGlhbGx5IHdpbGwgYmUgcHJvdmlkaW5nIHRoZSBJUEZJWCBzZXJ2aWNl IGZvciB0aGUgVlBOcyANdGhhdCBpdCBwcm92aWRlcyBjb25uZWN0aXZpdHkuDQ1UaGUgZXhwb3J0 ZXIgaW4gTGF5ZXIgMyBQRS1iYXNlZCBWUE4gY2FuIGJlIGxvY2F0ZWQgb24gdGhlIGN1c3RvbWVy J3MgDW5ldHdvcmssIG9uIHRoZSBTUCdzIGJhY2tib25lIChQIFJvdXRlcikgb3Igb24gdGhlIGVk Z2UgKFBFIHJvdXRlcikuIA1UaGUgcHJlbWlzZSBvZiB0aGlzIGRpc2N1c3Npb24gaXMgdGhhdCB0 aGUgZXhwb3J0ZXIgaXMgdGhlIG9uZSANcHJvdmlkaW5nIG1pZGRsZWJveCBzZXJ2aWNlcywgc28g aW4gdGhlIGNhc2Ugb2YgVlBOcyB3ZSBhc3N1bWUgdGhhdCANdGhlIGV4cG9ydGVyIGlzIGxvY2F0 ZWQgaW4gYSBQRSBkZXZpY2UuIA0NNC4zLjUuMS4xLiBUdW5uZWxpbmcNDVtUT0RPIGZvciBSZWlu YWxkbyA/XQ0NW1RPIERPIFJlaW5hbGRvXQ0NDQ00LjMuNS4xLjIuIE92ZXJsYXBwaW5nIEFkZHJl c3MgUmVhbG1zDQ1JbiB0aGUgY2FzZSB0aGUgZXhwb3J0ZXIgcGxheXMgdGhlIHJvbGUgb2YgYSBQ RSByb3V0ZXIgW1ZQTi0yNTQ3QklTXSANaW4gYSBwcm92aWRlciBwcm92aXNpb25lZCBWUE4gc2Nl bmFyaW8gYW5kIGhhcyBWUE5zIHdpdGggb3ZlcmxhcHBpbmcgDXByaXZhdGUgYWRkcmVzcyByZWFs bXMsIGl0IGNhbiBvbmx5IHByb3ZpZGUgdXNlZnVsIG5vbi1jb25mbGljdGluZyANaW5mb3JtYXRp b24gdG8gdGhlIHByb3ZpZGVyIGZvciBpbnRyYS1WUE4gdHJhZmZpYyBpZiBpdCB1c2VzIGEgDXRl Y2huaXF1ZSB0aGF0IGFsbG93cyB0aGUgY29sbGVjdG9yIHRvIHVuaXF1ZWx5IGlkZW50aWZ5IHRv IHdoaWNoIFZQTiANdGhlIGZsb3cgYmVsb25ncy4NDVNldmVyYWwgdGVjaG5pcXVlcyBjb3VsZCBi ZSB1c2VkIHRvIGFjY29tcGxpc2ggdGhpcyBnb2FsLiBPbmUgb2YgDXRoZXNlIHRlY2huaXF1ZXMg aXMgdG8gaW5jbHVkZSB0aGUgVlBOIEdsb2JhbCB1bmlxdWUgaWRlbnRpZmllciBbVlBOLQ1JRF0g YXMgb25lIG9mIHRoZSBrZXlzIGluIHRoZSBmbG93IHJlY29yZC4gDQ1JbiB0aGUgY2FzZSB0aGUg ZXhwb3J0ZXIgc3VwcG9ydHMgVlBOcyB3aXRoIG92ZXJsYXBwaW5nIHByaXZhdGUgDWFkZHJlc3Mg cmVhbG1zLCBpdCBNVVNUIGluY2x1ZGUgdGhlIFZQTi1JRCBbVlBOLUlEXSBpbiB0aGUgZXhwb3J0 ZWQgDWZsb3cgcmVjb3JkLg0NNC4zLjUuMi4gTGF5ZXIgMiBQRS1iYXNlZCBWUE4gW1RCRF0NDUEg bGF5ZXIgMiBQRS1iYXNlZCBWUE4gaXMgb25lIGluIHdoaWNoIHRoZSBuZXR3b3JrIGlzIGF3YXJl IG9mIHRoZSANVlBOLCBidXQgZG9lcyBvbmx5IGxheWVyIDIgZm9yd2FyZGluZyBhbmQgc2lnbmFs aW5nLiAgVGhpcyBpbXBsaWVzIA10aGF0IHRoZSBTUCBwcm92aXNpb25zIGFuZCBtYWludGFpbnMg bGF5ZXIgMiBjb25uZWN0aXZpdHkgYmV0d2VlbiBDRSANZGV2aWNlcyBbVlBOLUwyXS4NDUZvcndh cmRpbmcgb3B0aW9ucyBpbmNsdWRlIE1BQyBhZGRyZXNzZXMgKHN1Y2ggYXMgTEFOIGVtdWxhdGlv biksIHVzZSANb2YgcG9pbnQtdG8tcG9pbnQgbGluayBsYXllciBjb25uZWN0aW9ucyAoRlIgb3Ig QVRNKSwgbXVsdGlwb2ludC10by0NcG9pbnQgKHVzaW5nIE1QTFMgbXVsdGlwb2ludCB0byBwb2lu dCBMU1BzKSwgYW5kIHBvaW50LXRvLW11bHRpcG9pbnQgDShlLmcuLCBBVE0gVkNDcykuDQ1Gb3Ig YSBsYXllciAyIFBFLWJhc2VkIFZQTiwgdGhlIFBFIGRldmljZSBtYXkgYmUgYSByb3V0ZXIsIExT Uiwgb3IgSVAgDXN3aXRjaC4gIEZyb20gdGhlIENFJ3MgcGVyc3BlY3RpdmUsIHRoZSBQRSB3aWxs IGJlIG9wZXJhdGluZyBhcyBhIA1zd2l0Y2guDQ00LjQuIElQRklYIGFuZCBSTU9OIA1bVE9ET10g DQ00LjUuIElQRklYIGFuZCBJUFBNIA0NW1RPRE8gZm9yIFRhbmphXSANDQ00LjYuIElQRklYIGFu ZCBQU0FNUCANDVtUT0RPIGZvciBUYW5qYSA/XSANDQ0gDVtmdXJ0aGVyIHJlbGF0aW9ucyA/XQ0N DQ0NNS4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbg0NW1RPRE9dDQ0NNi4gUmVmZXJlbmNlcw0NW1F1 WkMwMl0gSi4gUXVpdHRlayAsZXQuIEFsICJSZXF1aXJlbWVudHMgZm9yIElQIEZsb3cgSW5mb3Jt YXRpb24gDUV4cG9ydCAiLCAod29yayBpbiBwcm9ncmVzcykgLEludGVybmV0IERyYWZ0LCBJbnRl cm5ldCBFbmdpbmVlcmluZyANVGFzayBGb3JjZSwgPGRyYWZ0LWlldGYtaXBmaXgtcmVxcy0wMS50 eHQ+LCBGZWJydWFyeSAyMDAyDQ1bV29vZDAyXU0uIFdvb2QgLGV0IGFsLiwiIEludHJ1c2lvbiBE ZXRlY3Rpb24gTWVzc2FnZSBFeGNoYW5nZSANUmVxdWlyZW1lbnRzIiwod29yayBpbiBwcm9ncmVz cyksIEludGVybmV0IERyYWZ0LCBJbnRlcm5ldCANRW5naW5lZXJpbmcgVGFzayBGb3JjZSwgZHJh ZnQtaWV0Zi1pZHdnLXJlcXVpcmVtZW50cy0wNixGZWJydWFyeSANMjAwMi4NDVtBd2R1MDJdIERh bmllbCBPLiBBd2R1Y2hlLCBldC4gYWwuLCIgT3ZlcnZpZXcgYW5kIFByaW5jaXBsZXMgb2YgDUlu dGVybmV0IFRyYWZmaWMgRW5naW5lZXJpbmciLCAod29yayBpbiBwcm9ncmVzcyksIEludGVybmV0 IERyYWZ0LCANSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSwgZHJhZnQtaWV0Zi10ZXdn LXByaW5jaXBsZXMtMDIudHh0LCANTWF5IDIwMDIgDQ1bQnJvdzAwXSBOZXZpbCBCcm93bmxlZTog UGFja2V0IE1hdGNoaW5nIGZvciBOZVRyYU1ldCBEaXN0cmlidXRpb25zLCANaHR0cDovL3d3dzIu YXVja2xhbmQuYWMubnovbmV0Ly9JbnRlcm5ldC9ydGZtL21lZXRpbmdzLzQ3LQ1hZGVsYWlkZS9w cC1kaXN0Lw0NW0RlQ2kwMV0gQy4gRGVtaWNoZWxpcywgUC4gQ2ltZW50bzogSVAgUGFja2V0IERl bGF5IFZhcmlhdGlvbiBNZXRyaWMgDWZvciBJUFBNLCA8ZHJhZnQtaWV0Zi1pcHBtLWlwZHYtMDgu dHh0PiwgTm92ZW1iZXIgICAyMDAxDQ1bUkZDMjY4MF0gRy4gQWxtZXMsIFMuIEthbGlkaW5kaSwg TS4gWmVrYXVza2FzOiBBIE9uZS13YXkgUGFja2V0IExvc3MgDU1ldHJpYyBmb3IgSVBQTSwgU2Vw dGVtYmVyIDE5OTkNDVtDbFBCOTNdIEsuQy4gQ2xhZmZ5LCBHZW9yZ2UgQyBQb2x5em9zLCBIYW5z LVdlcm5lciBCcmF1bjogDUFwcGxpY2F0aW9uIG9mIFNhbXBsaW5nIE1ldGhvZG9sb2dpZXMgdG8g TmV0d29yayBUcmFmZmljIA1DaGFyYWN0ZXJpemF0aW9uLCBQcm9jZWVkaW5ncyBvZiBBQ00gU0lH Q09NTSc5MywgDVNhbiBGcmFuY2lzY28sIENBLCBVU0EsICBTZXB0ZW1iZXIgMTMgLSAxNywgMTk5 Mw0NW0dyRE05OF0gSWFuIEQuIEdSQUhBTSwgU3RlcGhlbiBGLiBET05ORUxMWSwgU3RlbGUgTUFS VElOLCBKZWQgDU1BUlRFTlMsIEpvaG4gRy4gQ0xFQVJZOiANTm9uaW50cnVzaXZlIGFuZCBBY2N1 cmF0ZSBNZWFzdXJlbWVudCBvZiBVbmlkaXJlY3Rpb25hbCBEZWxheSBhbmQgDURlbGF5IFZhcmlh dGlvbiBvbiB0aGUgSW50ZXJuZXQsIElORVQnOTgsIEdlbmV2YSwgU3dpdHplcmxhbmQsICANMjEt MjQgSnVseSwgMTk5OA0NW0R1R3IwMF0gTmljayBEdWZmaWVsZCwgTWF0dGhpYXMgR3Jvc3NnbGF1 c2VyOiAiVHJhamVjdG9yeSBTYW1wbGluZyANZm9yIERpcmVjdCBUcmFmZmljIE9ic2VydmF0aW9u IiwgUHJvY2VlZGluZ3Mgb2YgQUNNIFNJR0NPTU0gMjAwMCwgDVN0b2NraG9sbSwgU3dlZGVuLCBB dWd1c3QgMjggLSBTZXB0ZW1iZXIgMSwgMjAwMC4NDVtSRkMyNjc5XSBHLiBBbG1lcywgUy4gS2Fs aWRpbmRpLCBNLiBaZWthdXNrYXM6IEEgT25lLXdheSBEZWxheSANTWV0cmljIGZvciBJUFBNLCBS ZXF1ZXN0IGZvciBDb21tZW50czogMjY3OSwgU2VwdGVtYmVyIDE5OTkgIA0NW1pzWkMwMV0gVGFu amEgWnNlYnksIFNlYmFzdGlhbiBaYW5kZXIsIEdlb3JnIENhcmxlOiBFdmFsdWF0aW9uIA1vZiBC dWlsZGluZyBCbG9ja3MgDWZvciBQYXNzaXZlIE9uZS13YXktZGVsYXkgTWVhc3VyZW1lbnRzLCBQ cm9jZWVkaW5ncyBvZiBQYXNzaXZlIGFuZCANQWN0aXZlIE1lYXN1cmVtZW50IFdvcmtzaG9wIChQ QU0gMjAwMSksIEFtc3RlcmRhbSwgVGhlIE5ldGhlcmxhbmRzLCANQXByaWwgMjMtMjQsIDIwMDEg DQ1bTUNGV10gU3Jpc3VyZXNoLCBTLiBldCBhbC4gICJNaWRkbGVib3ggQ29tbXVuaWNhdGlvbiBB cmNoaXRlY3R1cmUgDWFuZCBmcmFtZXdvcmssIiB3b3JrIGluIHByb2dyZXNzLiAgT2N0b2JlciAy MDAxLg0NW05BVC1URVJNXSBTcmlzdXJlc2gsIFAuIGFuZCBNLiBIb2xkcmVnZSwgIklQIE5ldHdv cmsgQWRkcmVzcyANVHJhbnNsYXRvciAoTkFUKSBUZXJtaW5vbG9neSBhbmQgQ29uc2lkZXJhdGlv bnMiLCBSRkMgMjY2MywgQXVndXN0IA0xOTk5Lg0NW05BVC1UUkFEXSBTcmlzdXJlc2gsIFAuIGFu ZCBLLiBFZ2V2YW5nLCAiVHJhZGl0aW9uYWwgSVAgTmV0d29yayAgDUFkZHJlc3MgVHJhbnNsYXRv ciAoVHJhZGl0aW9uYWwgTkFUKSIsIFJGQyAzMDIyLCBKYW51YXJ5ICAyMDAxLg0NW1BQVlBOLUZS XSBDYWxsb24sIFIuLCBTdXp1a2ksIE0uLCBldCBhbC4gIkEgRnJhbWV3b3JrIGZvciBQcm92aWRl ciANUHJvdmlzaW9uZWQgVmlydHVhbCBQcml2YXRlIE5ldHdvcmtzICIsIHdvcmsgaW4gcHJvZ3Jl c3MsIDxkcmFmdC0NaWV0Zi1wcHZwbi1mcmFtZXdvcmstMDMudHh0PiwgSmFudWFyeSAyMDAyLiAN DVtWUE4tTDJdIFJvc2VuLCBFLiwgIkFuIEFyY2hpdGVjdHVyZSBmb3IgTDJWUE5zLCIgSW50ZXJu ZXQtZHJhZnQgDTxkcmFmdC1pZXRmLXBwdnBuLWwydnBuLTAwLnR4dD4sIEp1bHkgMjAwMS4NDVtS RkMyNDc1XSBCbGFjaywgRC4sIEJsYWtlLCBTLiwgQ2FybHNvbiwgTS4sIERhdmllcywgRS4sIFdh bmcsIFouIGFuZCANVy4gV2Vpc3MsICJBbiBBcmNoaXRlY3R1cmUgZm9yIERpZmZlcmVudGlhdGVk IFNlcnZpY2VzIiwgUkZDIDI0NzUsIA1EZWNlbWJlciAxOTk4Lg0NDTcuIEFja25vd2xlZGdlbWVu dHMNDTguIEF1dGhvcidzIEFkZHJlc3Nlcw0NUmVpbmFsZG8gUGVubm8NTm9ydGVsIE5ldHdvcmtz LCBJbmMuIA0yMzA1IE1pc3Npb24gQ29sbGVnZSBCb3VsZXZhcmQNQnVpbGRpbmcgU0M5LUIxMjQw ICANU2FudGEgQ2xhcmEsIENBIDk1MTM0DUVtYWlsOiBycGVubm9Abm9ydGVsbmV0d29ya3MuY29t IA0NVGFuamEgWnNlYnkNRnJhdW5ob2ZlciBJbnN0aXR1dGUgZm9yIE9wZW4gQ29tbXVuaWNhdGlv biBTeXN0ZW1zKEZPS1VTKSAgDUthaXNlcmluLUF1Z3VzdGEtQWxsZWUgMzEgIA0xMDU4OSBCZXJs aW4gIA1HZXJtYW55ICANUGhvbmU6ICs0OSAzMCAzNDYzIDcxNTMgIA1FbWFpbDogenNlYnlAZm9r dXMuZmhnLmRlDQ0NDTkuIEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudA0NIkNvcHlyaWdodCAoQykg VGhlIEludGVybmV0IFNvY2lldHkgKGRhdGUpLiBBbGwgUmlnaHRzIFJlc2VydmVkLiANVGhpcyBk b2N1bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQgYW5kIGZ1cm5pc2hl ZCB0byANb3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24gb3Igb3Ro ZXJ3aXNlIGV4cGxhaW4gDWl0IG9yIGFzc2lzdCBpbiBpdHMgaW1wbGVtZW50YXRpb24gbWF5IGJl IHByZXBhcmVkLCBjb3BpZWQsIA1wdWJsaXNoZWQgYW5kIGRpc3RyaWJ1dGVkLCBpbiB3aG9sZSBv ciBpbiBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9uIA1vZiBhbnkga2luZCwgcHJvdmlkZWQgdGhh dCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyANcGFyYWdyYXBoIGFyZSBpbmNs dWRlZCBvbiBhbGwgc3VjaCBjb3BpZXMgYW5kIGRlcml2YXRpdmUgd29ya3MuIA1Ib3dldmVyLCB0 aGlzIGRvY3VtZW50IGl0c2VsZiBtYXkgbm90IGJlIG1vZGlmaWVkIGluIGFueSB3YXksIHN1Y2gg DWFzIGJ5IHJlbW92aW5nIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8gdGhl IEludGVybmV0IA1Tb2NpZXR5IG9yIG90aGVyIEludGVybmV0IG9yZ2FuaXphdGlvbnMsIGV4Y2Vw dCBhcyBuZWVkZWQgZm9yIHRoZSANcHVycG9zZSBvZiBkZXZlbG9waW5nIEludGVybmV0IHN0YW5k YXJkcyBpbiB3aGljaCBjYXNlIHRoZSANcHJvY2VkdXJlcyBmb3IgY29weXJpZ2h0cyBkZWZpbmVk IGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyANbXVzdCBiZSBmb2xsb3dlZCwgb3Ig YXMgcmVxdWlyZWQgdG8gdHJhbnNsYXRlIGl0IGludG8uDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAIw8AAEIPAAAP EAAAJRAAAHgQAAB5EAAAvRAAAMYQAADXEAAA5hAAAPIQAADzEAAA9RAAAPcQAAAQEQAAlhEAAKUR AACmEQAAqxEAAKwRAAD8EQAA/REAABMSAAAuEgAANBIAAFkSAABbEgAAahIAAGsSAAAsEwAAMBMA ADITAAD99P3r/eL92dD9w7DDnYqB0HjQeNB40G9mb/1deF3ZVAAAAAARAAiBUEoDAGNIAQBkaHCB ZEYRAQiBBEgBAAVoeoFkRlBKAwARAAiBUEoDAGNIAQBkaG+BZEYRAAiBUEoDAGNIAQBkaHmBZEYR AQiBBEgBAAVoh4FkRlBKAwARAQiBBEgBAAVodYFkRlBKAwAlAQiBBEgBAAVodYFkRkNKFABPSgQA UEoDAFFKBABeSgQAYUoUACUACIFDShQAT0oEAFBKAwBRSgQAXkoEAGFKFABjSAEAZGh1gWRGJQEI gQRIAQAFaGeBZEZDShQAT0oEAFBKAwBRSgQAXkoEAGFKFAAYQ0oUAE9KBABQSgMAUUoEAF5KBABh ShQAABEBCIEESAEABWiGgWRGUEoDABEACIFQSgMAY0gBAGRoeoFkRhEBCIEESAEABWhngWRGUEoD ABEACIFQSgMAY0gBAGRoZoFkRhEACIFQSgMAY0gBAGRoZYFkRgRQSgMAIAAEAAAbBAAATQQAAG4E AACgBAAArgQAAK8EAACwBAAAxwQAAMgEAADJBAAA3QQAAN4EAAAiBQAAUAUAAFEFAACUBQAA1QUA ABUGAABZBgAAmQYAAN0GAAAbBwAAJwcAACgHAABgBwAAjgcAANAHAADxBwAA8gcAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAdAAQAANeAAAD9AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAABAQHyBwAA8wcAAPwHAAD9BwAA PggAAIIIAADFCAAAxggAAOgIAADpCAAALgkAAHAJAACyCQAAswkAALQJAADGCQAA1wkAAPIJAAAP CgAAMwoAAFkKAAB/CgAAoAoAANkKAAAQCwAAOAsAAGsLAACQCwAAvwsAAPgLAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHfgLAAANDAAAMwwAAHAMAACG DAAAsgwAAMQMAADpDAAACA0AABwNAAArDQAAQg0AAFkNAABxDQAAjg0AAJ8NAAC2DQAAzw0AAO4N AADvDQAA8A0AAPENAAABDgAAAg4AAEcOAACHDgAAyA4AAAQPAAAhDwAAIg8AAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAdIg8AACMPAAAzDwAAQw8AAEQP AABdDwAAXg8AAHoPAACMDwAAjQ8AALAPAACyDwAAuQ8AALoPAAC7DwAA4A8AAOEPAADoDwAA6Q8A AOoPAAAPEAAAJRAAACYQAABrEAAArRAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AABitEAAAEBEAAFsRAACsEQAAtgAA AAAAAAAAAAAAAHEAAAAAAAAAAAAAAAAsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAEQPAEMkAUXGgAAAAQCGgWRGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQPAEMkAUXGgAAAAQB1gWRGAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAASQAANyQAOCQAQyQBRcaAAAABAHWBZEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIJAAAA6wRAAD9EQAAExIAABwSAABrEgAA lBIAAMASAAABEwAALBMAADITAAB2EwAAjhMAAI8TAAC6AAAAAAAAAAAAAAAAugAAAAAAAAAAAAAA ALgAAAAAAAAAAAAAAABzAAAAAAAAAAAAAAAAugAAAAAAAAAAAAAAAHMAAAAAAAAAAAAAAABzAAAA AAAAAAAAAAAAcwAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAA AAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAw8AQyQBAEQPAEMkAUXGgAAAAQB6gWRG AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEPAABEDwBDJAFFxoAAAAEAh4FkRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMMhMAAI0TAACkFAAAsRQAAFMVAABw FQAAzhUAACMWAAAmFgAAWxYAAHsWAAD2FgAA9xYAAAosAAApLAAALiwAAEUsAAC1LgAAti4AAB8v AAAgLwAAMC8AADEvAACDLwAAmC8AAOYvAAAbMAAA1DAAABMxAABIMQAAajEAAFUyAACOMgAA0jIA APoyAAD7MgAA9vPq4djzz/PG872086vzovOZ85mQh/N+837zdfN182xjWmwAEQEIgQRIAQAFaGOC ZEZQSgMAEQEIgQRIAQAFaGKCZEZQSgMAEQEIgQRIAQAFaGCCZEZQSgMAEQEIgQRIAQAFaF+CZEZQ SgMAEQEIgQRIAQAFaF6CZEZQSgMAEQAIgVBKAwBjSAEAZGhWgmRGEQEIgQRIAQAFaFaCZEZQSgMA EQEIgQRIAQAFaF2CZEZQSgMAEQAIgVBKAwBjSAEAZGgGgmRGEQEIgQRIAQAFaAaCZEZQSgMAEQAI gVBKAwBjSAEAZGgFgmRGEQEIgQRIAQAFaAWCZEZQSgMAEQAIgVBKAwBjSAEAZGhvgWRGEQEIgQRI AQAFaG+BZEZQSgMAEQEIgQRIAQAFaIGBZEZQSgMAEQEIgQRIAQAFaHuBZEZQSgMAEQEIgQRIAQAF aI+BZEZQSgMABFBKAwAAEQAIgVBKAwBjSAEAZGh6gWRGACOPEwAAzhMAABUUAABTFAAAkBQAAKIV AADPFQAA0BUAACQWAAAmFgAAXBYAAF0WAAD4FgAA+RYAAEAXAACGFwAAyhcAAAgYAABOGAAAkhgA ANQYAAAWGQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAA AAAAAABEDwBDJAFFxoAAAAEAb4FkRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAFRYZAABUGQAAlxkAANcZAAAdGgAAHhoA AFQaAABVGgAAnBoAAOEaAAAmGwAAZRsAAKkbAADwGwAANBwAAHUcAAC4HAAA8xwAADodAAB/HQAA vx0AAAMeAABKHgAAjB4AAM8eAAAPHwAAVh8AAJkfAADgHwAA8h8AAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAd8h8AAPMfAAAnIAAAKCAAAG4gAACyIAAA +CAAAD0hAACDIQAAySEAAAwiAABSIgAAmSIAANgiAAAZIwAAWSMAAJ8jAADiIwAAJSQAAFYkAABX JAAAfCQAAH0kAADBJAAABCUAAEslAACPJQAAziUAABUmAABcJgAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB1cJgAAZCYAAGUmAACVJgAAliYAANwmAAAZ JwAAXCcAAJgnAACmJwAApycAAMknAADKJwAABigAAE0oAACQKAAA1CgAABYpAABbKQAAoikAAN4p AAAjKgAAaCoAAK4qAADzKgAAMisAAHQrAAC5KwAAyysAAMwrAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHcwrAAD5KwAA+isAACosAAArLAAALCwAAEYs AABHLAAAfywAAIAsAACBLAAAlSwAAJYsAADTLAAAGi0AAGEtAACmLQAA6C0AAC4uAABzLgAAuy4A AAIvAABXLwAAsS8AACIwAABoMAAArDAAAC4xAACRMQAA0zEAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAd0zEAABgyAAACMwAASDMAAI8zAAC/MwAAwDMA AMEzAADCMwAA5TMAAOYzAAArNAAAbjQAALA0AADxNAAANTUAAHg1AACVNQAAljUAAMI1AADuNQAA GjYAACg2AAA/NgAATTYAAFs2AABxNgAAhzYAAJ02AACzNgAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB2zNgAAyTYAAOM2AADxNgAABTcAABM3AAAoNwAA PTcAAFU3AABWNwAAlzcAAJg3AACZNwAA1DcAANU3AAAaOAAAVDgAAJU4AADYOAAAGjkAAFY5AACb OQAA2zkAAB86AABhOgAAnjoAANw6AADdOgAA3joAAN86AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHfsyAADCOgAA2zoAAGxSAABtUgAAUlMAAFNTAACx XgAAs14AAMxfAADeXwAA/F8AAA9gAAA1YAAASGAAAJpqAACwagAAw2oAAMRqAADXgAAA/fT96/3i /dn90P3Q/dD9x9DH/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQAIgVBKAwBjSAEAZGgIgmRGEQEIgQRIAQAFaAiC ZEZQSgMAEQEIgQRIAQAFaAeCZEZQSgMAEQAIgVBKAwBjSAEAZGiSgWRGEQEIgQRIAQAFaJKBZEZQ SgMAEQEIgQRIAQAFaGOCZEZQSgMABFBKAwAT3zoAAOA6AAAMOwAAODsAAGQ7AAByOwAAgDsAAJk7 AACyOwAAyzsAAOQ7AAD9OwAACzwAAB88AAAtPAAAQjwAAFc8AABsPAAAbTwAAJw8AACdPAAAnjwA ALM8AADFPAAAxjwAAPE8AADyPAAANz0AAH49AADCPQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB3CPQAABT4AAEs+AACKPgAAzD4AAM0+AAAOPwAAVD8A AJU/AADcPwAAIEAAAExAAABNQAAAlEAAANBAAAD2QAAA90AAAAdBAAAIQQAASUEAAI1BAADPQQAA 30EAAOBBAAAnQgAAZ0IAAKhCAADrQgAA8UIAAPJCAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAAAAAAAAAAAAAAABDwAAHfJCAAAFQwAABkMAAEtDAABlQwAAZkMAAIBDAACBQwAA yEMAAOJDAADjQwAAF0QAABhEAABfRAAAoEQAAKtEAACsRAAAz0QAANBEAAATRQAAVEUAAJhFAADd RQAAG0YAAGJGAAB/RgAAgEYAAMVGAAALRwAAT0cAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAdT0cAAJZHAADbRwAAHkgAAGRIAACqSAAAq0gAAO1IAAAz SQAAb0kAAI5JAACPSQAAqEkAAKlJAADoSQAAL0oAAHJKAAC3SgAA/UoAAEBLAABBSwAAhEsAAMhL AAANTAAAU0wAAJhMAADdTAAAHE0AAGNNAAB0TQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB10TQAAdU0AALtNAAD8TQAAPU4AAFVOAABWTgAAV04AAHNO AAB0TgAAuE4AAPxOAAA9TwAAf08AAMRPAADLTwAAzE8AAN9PAADgTwAAHVAAAF5QAACdUAAA4VAA ACNRAABpUQAAdVEAAHZRAAC8UQAAAFIAAEZSAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAAAAAAAAAAAAAAABDwAAHUZSAABPUgAAUFIAAGxSAABtUgAAr1IAAPBSAAAxUwAAUVMA AFJTAACTUwAAu1MAALxTAADOUwAAFFQAAFVUAACZVAAA4FQAACZVAABqVQAAr1UAALxVAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAEQPAEMkAUXG gAAAAQCSgWRGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEPAAAVvFUAAL1VAAAFVgAAPVYAAD5WAABOVgAAT1YAAJZWAAC5VgAA ulYAAMpWAADLVgAABFcAAAVXAAAjVwAAJFcAAGpXAACwVwAA0VcAANJXAADjVwAA5FcAACtYAABy WAAAtVgAAPdYAAD4WAAAPVkAAH9ZAACAWQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQ8AAB2AWQAAklkAAJNZAADXWQAAGloAAGBaAAChWgAA0FoAANFaAAAV WwAAW1sAAIFbAACCWwAAwlsAAARcAABGXAAAbVwAAG5cAAB/XAAAgFwAAMBcAAAFXQAASF0AAIxd AADSXQAAFV4AAFpeAAB4XgAAeV4AAMFeAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAAAAAAAAAAAAAAABDwAAHcFeAAD9XgAAP18AAIZfAACuXwAAr18AAM1fAADOXwAA318AAOBf AAD9XwAA/l8AAA9gAAAQYAAAEWAAADZgAAA3YAAASGAAAElgAABKYAAAS2AAAFdgAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAEQPAEMkAUXGgAAA AQAIgmRGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAEPAAAVV2AAAFhgAACeYAAA1mAAABphAABhYQAAp2EAAO1hAAAxYgAAa2IA AGxiAACwYgAA8GIAADFjAAB4YwAAvmMAAARkAAAcZAAAHWQAAB5kAAA8ZAAAPWQAAINkAADFZAAA DGUAAFJlAACZZQAA32UAACBmAAAhZgAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAQ8AAB0hZgAAZWYAAKdmAADrZgAALWcAAFNnAABUZwAAm2cAAOFnAAARaAAA EmgAAFZoAACZaAAA4WgAAChpAABHaQAASGkAAI9pAADVaQAAFWoAAFpqAACDagAAhGoAAJlqAACa agAAsGoAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAABDwAAGbBqAACxagAAwmoAAMRqAADFagAA62oAAOxqAAAyawAAeGsAALxrAAD8 awAAQ2wAAFVsAABWbAAAmGwAAN5sAAAKbQAAC20AAExtAACRbQAAnm0AAJ9tAAC6AAAAAAAAAAAA AAAAugAAAAAAAAAAAAAAALoAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgA AAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAA AAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAA ALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAA AAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAABEDwBDJAFFxoAA AAEACIJkRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAVn20AAMNtAADEbQAACG4AAExuAACSbgAApG4AAKVuAADsbgAAMW8AAHdv AACJbwAAim8AANFvAAAUcAAAHHAAAB1wAAAycAAAOnAAADtwAABQcAAAUXAAAGNwAABkcAAAZXAA AHtwAAB8cAAAkHAAAJFwAACScAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQ8AAB2ScAAAlHAAAKpwAACrcAAArHAAAK1wAACucAAAyHAAAMlwAADQcAAA0XAA ANJwAADgcAAA4XAAACRxAABocQAAonEAAKNxAADjcQAAH3IAAGFyAABncgAAaHIAAKpyAADucgAA M3MAAD1zAAA+cwAAhHMAAL9zAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAA AAAAAAAAAAABDwAAHb9zAADRcwAA0nMAABh0AABRdAAAUnQAAJl0AAC5dAAAunQAAPZ0AAAwdQAA YnUAAJN1AACUdQAA1HUAAO51AAAxdgAAcnYAAIN2AACEdgAAyXYAAAx3AAA+dwAAP3cAAIB3AAC+ dwAAv3cAAAB4AAAUeAAAWHgAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEPAAAdWHgAAJ14AACweAAAsXgAAPV4AAAmeQAAJ3kAAGZ5AACqeQAAsHkAALF5AAD0 eQAANHoAADV6AAB6egAAvHoAAOl6AADqegAALHsAAFh7AABZewAAoHsAAOR7AADzewAA9HsAAPV7 AAAJfAAACnwAACB8AAAhfAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQ8AAB0hfAAAMHwAAEd8AABmfAAAe3wAAJF8AACzfAAAtHwAAMB8AAD9fAAAGX0AACh9 AAAyfQAATH0AAGZ9AABnfQAAaH0AAGl9AACFfQAAhn0AAMh9AAANfgAAUH4AAI1+AADSfgAAEn8A AFN/AACXfwAA2n8AAB2AAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAA AAAAAAABDwAAHR2AAABZgAAAnoAAANWAAADWgAAA14AAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAEPAAAFIAAxkGgBH7DQLyCw4D0hsCcFIrAnBSOQoAUkkKAFJbAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAUABEACgABAGkADwADAAAAAAAAAAAAOAAAQPH/AgA4AAwABgBOAG8AcgBtAGEAbAAA AAIAAAAYAENKGABfSAEEYUoYAG1ICQRzSAkEdEgJBAAAAAAAAAAAAAAAAAAAAAAAADwAQUDy/6EA PAAMABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAAAAA AAAAAAA8AFpAAQDyADwADAAKAFAAbABhAGkAbgAgAFQAZQB4AHQAAAACAA8AFABDShQAT0oEAFFK BABeSgQAYUoUAEQA/m/x/wIBRAAMAAcARABlAGYAYQB1AGwAdAAAAAsAEAA3JAA4JABIJAAAGABP SgUAUUoFAF9IAQRtSAkEc0gJBHRICQQAAAAA0n8AAAQAANAAAAwA/////wAAAAAbAAAATQAAAG4A AACgAAAArgAAAK8AAACwAAAAxwAAAMgAAADJAAAA3QAAAN4AAAAiAQAAUAEAAFEBAACUAQAA1QEA ABUCAABZAgAAmQIAAN0CAAAbAwAAJwMAACgDAABgAwAAjgMAANADAADxAwAA8gMAAPMDAAD8AwAA /QMAAD4EAACCBAAAxQQAAMYEAADoBAAA6QQAAC4FAABwBQAAsgUAALMFAAC0BQAAxgUAANcFAADy BQAADwYAADMGAABZBgAAfwYAAKAGAADZBgAAEAcAADgHAABrBwAAkAcAAL8HAAD4BwAADQgAADMI AABwCAAAhggAALIIAADECAAA6QgAAAgJAAAcCQAAKwkAAEIJAABZCQAAcQkAAI4JAACfCQAAtgkA AM8JAADuCQAA7wkAAPAJAADxCQAAAQoAAAIKAABHCgAAhwoAAMgKAAAECwAAIQsAACILAAAjCwAA MwsAAEMLAABECwAAXQsAAF4LAAB6CwAAjAsAAI0LAACwCwAAsgsAALkLAAC6CwAAuwsAAOALAADh CwAA6AsAAOkLAADqCwAADwwAACUMAAAmDAAAawwAAK0MAAAQDQAAWw0AAKwNAAD9DQAAEw4AABwO AABrDgAAlA4AAMAOAAABDwAALA8AADIPAAB2DwAAjg8AAI8PAADODwAAFRAAAFMQAACQEAAAohEA AM8RAADQEQAAJBIAACYSAABcEgAAXRIAAPgSAAD5EgAAQBMAAIYTAADKEwAACBQAAE4UAACSFAAA 1BQAABYVAABUFQAAlxUAANcVAAAdFgAAHhYAAFQWAABVFgAAnBYAAOEWAAAmFwAAZRcAAKkXAADw FwAANBgAAHUYAAC4GAAA8xgAADoZAAB/GQAAvxkAAAMaAABKGgAAjBoAAM8aAAAPGwAAVhsAAJkb AADgGwAA8hsAAPMbAAAnHAAAKBwAAG4cAACyHAAA+BwAAD0dAACDHQAAyR0AAAweAABSHgAAmR4A ANgeAAAZHwAAWR8AAJ8fAADiHwAAJSAAAFYgAABXIAAAfCAAAH0gAADBIAAABCEAAEshAACPIQAA ziEAABUiAABcIgAAZCIAAGUiAACVIgAAliIAANwiAAAZIwAAXCMAAJgjAACmIwAApyMAAMkjAADK IwAABiQAAE0kAACQJAAA1CQAABYlAABbJQAAoiUAAN4lAAAjJgAAaCYAAK4mAADzJgAAMicAAHQn AAC5JwAAyycAAMwnAAD5JwAA+icAACooAAArKAAALCgAAEYoAABHKAAAfygAAIAoAACBKAAAlSgA AJYoAADTKAAAGikAAGEpAACmKQAA6CkAAC4qAABzKgAAuyoAAAIrAABXKwAAsSsAACIsAABoLAAA rCwAAC4tAACRLQAA0y0AABguAAACLwAASC8AAI8vAAC/LwAAwC8AAMEvAADCLwAA5S8AAOYvAAAr MAAAbjAAALAwAADxMAAANTEAAHgxAACVMQAAljEAAMIxAADuMQAAGjIAACgyAAA/MgAATTIAAFsy AABxMgAAhzIAAJ0yAACzMgAAyTIAAOMyAADxMgAABTMAABMzAAAoMwAAPTMAAFUzAABWMwAAlzMA AJgzAACZMwAA1DMAANUzAAAaNAAAVDQAAJU0AADYNAAAGjUAAFY1AACbNQAA2zUAAB82AABhNgAA njYAANw2AADdNgAA3jYAAN82AADgNgAADDcAADg3AABkNwAAcjcAAIA3AACZNwAAsjcAAMs3AADk NwAA/TcAAAs4AAAfOAAALTgAAEI4AABXOAAAbDgAAG04AACcOAAAnTgAAJ44AACzOAAAxTgAAMY4 AADxOAAA8jgAADc5AAB+OQAAwjkAAAU6AABLOgAAijoAAMw6AADNOgAADjsAAFQ7AACVOwAA3DsA ACA8AABMPAAATTwAAJQ8AADQPAAA9jwAAPc8AAAHPQAACD0AAEk9AACNPQAAzz0AAN89AADgPQAA Jz4AAGc+AACoPgAA6z4AAPE+AADyPgAABT8AAAY/AABLPwAAZT8AAGY/AACAPwAAgT8AAMg/AADi PwAA4z8AABdAAAAYQAAAX0AAAKBAAACrQAAArEAAAM9AAADQQAAAE0EAAFRBAACYQQAA3UEAABtC AABiQgAAf0IAAIBCAADFQgAAC0MAAE9DAACWQwAA20MAAB5EAABkRAAAqkQAAKtEAADtRAAAM0UA AG9FAACORQAAj0UAAKhFAACpRQAA6EUAAC9GAAByRgAAt0YAAP1GAABARwAAQUcAAIRHAADIRwAA DUgAAFNIAACYSAAA3UgAABxJAABjSQAAdEkAAHVJAAC7SQAA/EkAAD1KAABVSgAAVkoAAFdKAABz SgAAdEoAALhKAAD8SgAAPUsAAH9LAADESwAAy0sAAMxLAADfSwAA4EsAAB1MAABeTAAAnUwAAOFM AAAjTQAAaU0AAHVNAAB2TQAAvE0AAABOAABGTgAAT04AAFBOAABsTgAAbU4AAK9OAADwTgAAMU8A AFFPAABSTwAAk08AALtPAAC8TwAAzk8AABRQAABVUAAAmVAAAOBQAAAmUQAAalEAAK9RAAC8UQAA vVEAAAVSAAA9UgAAPlIAAE5SAABPUgAAllIAALlSAAC6UgAAylIAAMtSAAAEUwAABVMAACNTAAAk UwAAalMAALBTAADRUwAA0lMAAONTAADkUwAAK1QAAHJUAAC1VAAA91QAAPhUAAA9VQAAf1UAAIBV AACSVQAAk1UAANdVAAAaVgAAYFYAAKFWAADQVgAA0VYAABVXAABbVwAAgVcAAIJXAADCVwAABFgA AEZYAABtWAAAblgAAH9YAACAWAAAwFgAAAVZAABIWQAAjFkAANJZAAAVWgAAWloAAHhaAAB5WgAA wVoAAP1aAAA/WwAAhlsAAK5bAACvWwAAzVsAAM5bAADfWwAA4FsAAP1bAAD+WwAAD1wAABBcAAAR XAAANlwAADdcAABIXAAASVwAAEpcAABLXAAAV1wAAFhcAACeXAAA1lwAABpdAABhXQAAp10AAO1d AAAxXgAAa14AAGxeAACwXgAA8F4AADFfAAB4XwAAvl8AAARgAAAcYAAAHWAAAB5gAAA8YAAAPWAA AINgAADFYAAADGEAAFJhAACZYQAA32EAACBiAAAhYgAAZWIAAKdiAADrYgAALWMAAFNjAABUYwAA m2MAAOFjAAARZAAAEmQAAFZkAACZZAAA4WQAAChlAABHZQAASGUAAI9lAADVZQAAFWYAAFpmAACD ZgAAhGYAAJlmAACaZgAAsGYAALFmAADCZgAAxGYAAMVmAADrZgAA7GYAADJnAAB4ZwAAvGcAAPxn AABDaAAAVWgAAFZoAACYaAAA3mgAAAppAAALaQAATGkAAJFpAACeaQAAn2kAAMNpAADEaQAACGoA AExqAACSagAApGoAAKVqAADsagAAMWsAAHdrAACJawAAimsAANFrAAAUbAAAHGwAAB1sAAAybAAA OmwAADtsAABQbAAAUWwAAGNsAABkbAAAZWwAAHtsAAB8bAAAkGwAAJFsAACSbAAAlGwAAKpsAACr bAAArGwAAK1sAACubAAAyGwAAMlsAADQbAAA0WwAANJsAADgbAAA4WwAACRtAABobQAAom0AAKNt AADjbQAAH24AAGFuAABnbgAAaG4AAKpuAADubgAAM28AAD1vAAA+bwAAhG8AAL9vAADRbwAA0m8A ABhwAABRcAAAUnAAAJlwAAC5cAAAunAAAPZwAAAwcQAAYnEAAJNxAACUcQAA1HEAAO5xAAAxcgAA cnIAAINyAACEcgAAyXIAAAxzAAA+cwAAP3MAAIBzAAC+cwAAv3MAAAB0AAAUdAAAWHQAAJ10AACw dAAAsXQAAPV0AAAmdQAAJ3UAAGZ1AACqdQAAsHUAALF1AAD0dQAANHYAADV2AAB6dgAAvHYAAOl2 AADqdgAALHcAAFh3AABZdwAAoHcAAOR3AADzdwAA9HcAAPV3AAAJeAAACngAACB4AAAheAAAMHgA AEd4AABmeAAAe3gAAJF4AACzeAAAtHgAAMB4AAD9eAAAGXkAACh5AAAyeQAATHkAAGZ5AABneQAA aHkAAGl5AACFeQAAhnkAAMh5AAANegAAUHoAAI16AADSegAAEnsAAFN7AACXewAA2nsAAB18AABZ fAAAnnwAANV8AADWfAAA2XwAAJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoA AAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAP MAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAA AAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAA AACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACA AAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAA gJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoA AAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAP MAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAA AAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAA AACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACA AAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAA gJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoA AAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAP MAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAA AAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAA AACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACA AAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAAgJoAAAAPMAAAAAAAAACAAAAA gJoAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACA AAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAA gJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgAAEAAAyEwAA+zIAANeAAABFAAAATQAAAFUAAAAABAAA8gcAAPgLAAAiDwAArRAAAKwR AACPEwAAFhkAAPIfAABcJgAAzCsAANMxAACzNgAA3zoAAMI9AADyQgAAT0cAAHRNAABGUgAAvFUA AIBZAADBXgAAV2AAACFmAACwagAAn20AAJJwAAC/cwAAWHgAACF8AAAdgAAA14AAAEYAAABIAAAA SQAAAEoAAABLAAAATAAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABWAAAAVwAAAFgAAABZ AAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcA AAAABAAA14AAAEcAAAAAAAAAEwAAABoAAABDAAAARgAAAGgAAABtAAAAhQIAAI4CAAB/BwAAggcA ACMJAAAnCQAAhAsAAIkLAAAZDAAAIQwAAGISAABlEgAAzxIAANQSAAAMEwAADxMAAFQTAABXEwAA AxQAAAYUAAA1FAAAOBQAAD0XAABIFwAATxcAAFIXAABCHwAASh8AALojAAC9IwAA0CMAANMjAAAE KAAACSgAAL04AADCOAAA5DgAAO84AAD0OAAA/TgAAEM5AABMOQAA7TkAAPI5AAATOgAAHDoAAFE6 AABaOgAAYDoAAGk6AACTOgAAnDoAAKI6AACrOgAALjsAADc7AABvOwAAeDsAAIk8AACSPAAAND0A AD09AADQPQAA1D0AAO09AAD2PQAA7EEAAPRBAAAbQgAAJEIAAJNCAACcQgAA60IAAPRCAAAPQwAA GEMAAExMAABUTAAAzk8AANZPAAAUUAAAHVAAALdQAADAUAAA/FAAAAZRAABuUQAAd1EAAO5WAAD3 VgAAClcAABNXAABQWQAAVVkAANVbAADdWwAABVwAAA1cAAA+XAAARlwAAFJcAABWXAAA010AAN9d AACKXgAAjl4AAPpfAAD+XwAAmGIAAJxiAADrYgAA72IAABVjAAAZYwAAQmMAAEZjAADTYwAA2GMA AENkAABHZAAAImUAACZlAAAfZgAAKGYAAEVmAABJZgAApGYAAKxmAAC4ZgAAwGYAAGFnAABlZwAA LWkAADFpAABXawAAW2sAAIJrAACGawAAW2wAAGBsAACGbAAAi2wAAO1sAAD0bAAAe24AAIJuAABH bwAATG8AAGtvAABzbwAAv28AAMdvAADebwAA6G8AAO1vAAD0bwAAX3AAAGRwAABpcAAAcnAAAHdw AACAcAAAyHAAAM5wAADZcAAA4HAAAO5xAAD6cQAAknIAAJpyAAClcgAAsXIAAExzAABRcwAAVnMA AF9zAABkcwAAbXMAAMhzAADNcwAAznMAANNzAADfcwAA5XMAAOdzAADscwAAuHQAAMF0AADPdAAA 2HQAADJ1AAA7dQAAvHUAAMV1AADRdQAA2HUAAEB2AABGdgAAIXgAACl4AAAqeAAAL3gAALR4AAC5 eAAAungAAL94AADAeAAAyngAAP14AAATeQAAU3kAAGV5AADZfAAABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAAAAAABsAAAAgAAAAIgEAACUBAACUAQAAyQEAANUBAADaAQAA WQIAAFwCAACZAgAAogIAAN0CAADfAgAAGwMAACMDAACCBAAAhQQAAHAFAAB0BQAAhwoAAI8KAAAE CwAAEQsAABkMAAAjDAAAawwAAHQMAACtDAAAswwAABANAAATDQAAWw0AAGINAACsDQAArQ0AAP0N AAASDgAAaw4AAHQOAACWDgAAng4AAMIOAADKDgAAAw8AAAkPAADODwAA1w8AABUQAAAYEAAAUxAA AFwQAACQEAAAmxAAAKIRAACoEQAAXRIAAHwSAABAEwAAQxMAAIYTAACSEwAAyhMAANETAAAIFAAA EhQAAE4UAABZFAAAkhQAAJcUAAAWFQAAHxUAAFQVAABdFQAAlxUAAJ4VAADXFQAA4RUAAJwWAACh FgAA4RYAAOQWAAAvFwAANBcAAGUXAABuFwAAqRcAAK0XAADwFwAA8xcAADQYAAA5GAAAdRgAAH4Y AAC4GAAAwRgAAPMYAAACGQAAOhkAADwZAAB/GQAAhhkAAL8ZAADGGQAAAxoAAAgaAABKGgAATRoA AIwaAACTGgAAzxoAANYaAAAPGwAAFxsAAFYbAABbGwAAmRsAAJ0bAADgGwAA4hsAAG4cAABxHAAA shwAALgcAAD4HAAA/BwAAD0dAABEHQAAyR0AAMwdAAAMHgAAER4AAFIeAABVHgAAmR4AAJseAADY HgAA4R4AABkfAAAmHwAAWR8AAGEfAACfHwAAoR8AAOIfAADmHwAAJSAAAC8gAADBIAAAzCAAAAQh AAALIQAASyEAAFMhAADOIQAA2SEAABUiAAAXIgAAXCIAAGEiAADcIgAA3yIAABkjAAAjIwAAXCMA AGYjAACYIwAAoyMAAAYkAAARJAAATSQAAE8kAACQJAAAlyQAANQkAADXJAAAFiUAAB0lAABbJQAA YSUAAKIlAACkJQAA3iUAAOglAAAjJgAAJiYAAGgmAABtJgAAriYAALImAADzJgAA9iYAADInAAA6 JwAAdCcAAHwnAAC5JwAAwCcAANMoAADgKAAAGikAABwpAACmKQAArykAAC4qAAA1KgAAcyoAAHoq AAC7KgAAwCoAAAIrAAAKKwAAVysAAGIrAACxKwAAtSsAACIsAAAuLAAAaCwAAHYsAACsLAAAtywA AC4tAAA8LQAAkS0AAJstAADTLQAA3y0AABguAAAaLgAAAi8AAAwvAABILwAAUi8AAI8vAACRLwAA KzAAAC4wAABuMAAAdjAAALAwAAC7MAAA8TAAAPUwAAA1MQAAODEAAHkxAAB6MQAApzEAALIxAADi MQAA6DEAAHkyAAB/MgAAGjQAAB00AABUNAAAkzQAAJU0AAChNAAA2DQAAOE0AAAaNQAAHTUAAFY1 AABfNQAA2zUAAOY1AAAfNgAAKjYAAGE2AABnNgAAnjYAAKk2AADxNgAA/DYAACw3AAAyNwAA0jcA AN43AAA3OQAAOzkAAH45AACGOQAABToAAA06AABLOgAATDoAAIo6AACSOgAADjsAABY7AABUOwAA WTsAAJU7AACgOwAA3DsAAOM7AAAgPAAALDwAAJQ8AACcPAAA0DwAAN08AAAWPQAAIj0AAEk9AABS PQAAjT0AAJk9AAAnPgAALj4AAGc+AABvPgAAqD4AAK4+AADrPgAA7z4AAEs/AABNPwAAyD8AAMo/ AABfQAAAYUAAAKBAAACpQAAAE0EAABlBAABUQQAAW0EAAJhBAACbQQAA3UEAAN9BAAAbQgAAJEIA AGJCAABkQgAAxUIAAMpCAAALQwAALEMAAE9DAABSQwAAlkMAAJpDAADbQwAA4UMAAB5EAAApRAAA ZEQAAGlEAADtRAAA90QAADNFAAA2RQAAb0UAAHpFAADoRQAA9UUAAC9GAAAwRgAAckYAAHlGAAC3 RgAAvkYAAP1GAAAIRwAAhEcAAItHAADIRwAAy0cAAFNIAABdSAAAmEgAAJpIAADdSAAA30gAABxJ AAAnSQAAY0kAAGhJAAC7SQAAwUkAAPxJAAAFSgAAPUoAAEZKAAC4SgAAu0oAAPxKAAAFSwAAPUsA AEhLAAAdTAAAKEwAAF5MAABlTAAA4UwAAOxMAAAjTQAAKE0AALxNAADBTQAAAE4AAAROAABGTgAA TU4AAK9OAAC1TgAA8E4AAPpOAAAxTwAAOE8AAJNPAACaTwAAFFAAAB1QAABVUAAAXlAAAJlQAACc UAAA4FAAAOFQAAAmUQAAK1EAAGpRAABtUQAABVIAAAhSAACWUgAAn1IAAGpTAABwUwAAsFMAALNT AAArVAAALVQAAHJUAAB5VAAAtVQAALpUAAA9VQAAP1UAANdVAADcVQAAYFYAAGNWAAChVgAAp1YA ABVXAAAdVwAAW1cAAGBXAADCVwAAyVcAAARYAAAIWAAARlgAAExYAADAWAAAyFgAAAVZAAAIWQAA SFkAAExZAACMWQAAmFkAANJZAADUWQAAFVoAABlaAABaWgAAXloAAMFaAADFWgAA/VoAAAhbAAA/ WwAARFsAAIZbAACIWwAAnlwAAKVcAADWXAAA5FwAABpdAAAlXQAAYV0AAGpdAACnXQAAq10AAO1d AAD0XQAAMV4AADheAACwXgAAs14AADFfAAA4XwAAeF8AAHpfAAC+XwAAwl8AAARgAAAGYAAAg2AA AI1gAADFYAAAzGAAAAxhAAAPYQAAUmEAAFVhAACZYQAAm2EAAPJhAAD5YQAAZWIAAGliAACnYgAA r2IAAC1jAAA1YwAAm2MAAJ5jAADhYwAA6GMAAFZkAABdZAAA4WQAAORkAAAoZQAALGUAAI9lAACW ZQAAFWYAAB5mAABaZgAAXWYAADJnAAA0ZwAAeGcAAH9nAAC8ZwAAx2cAAPxnAAAFaAAAQ2gAAEZo AACYaAAAnWgAAExpAABTaQAAkWkAAJVpAAAIagAADGoAAExqAABQagAAkmoAAJlqAADsagAA7moA ADFrAAA2awAAeGsAAHlrAADRawAA12sAABRsAAAabAAAhmwAAI1sAACVbAAAnGwAAO1sAAD4bAAA P20AAEptAACkbQAAq20AAK5tAAC2bQAA8G0AAPJtAABWbgAAX24AAIRuAACGbgAAiG4AAIpuAAC/ bwAAx28AABhwAAAbcAAAdHAAAHVwAAB4cQAAhHEAAHhyAAB9cgAAyXIAAMxyAABhcwAAYnMAAOdz AADscwAAAHQAAAJ0AAAUdAAAF3QAALh0AADMdAAA9XQAAPh0AAAldgAAMnYAALx2AADAdgAALXcA ADJ3AADseAAA9HgAAA16AAATegAAUHoAAFJ6AACNegAAlnoAANJ6AADUegAAEnsAABt7AACXewAA mXsAAB18AAAkfAAAWXwAAGN8AACefAAAonwAANl8AAAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHAP//EgAAAAYAcgBwAGUAbgBuAG8AOwBEADoAXAB3AG8AcgBrAFwAcgBlAGkAbgBhAGwA ZABvAFwAZABvAGMAcwBcAGkAZQB0AGYAXABpAHAAZgBpAHgAXABpAHAAZgBpAHgALQBhAHAAcABs AGkAYwBhAGIAaQBsAGkAdAB5AC0AdgAxAC4AZABvAGMABgByAHAAZQBuAG4AbwBwAEMAOgBcAEQA bwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXAByAHAAZQBuAG4AbwBc AEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcA bwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABpAHAAZgBp AHgALQBhAHAAcABsAGkAYwBhAGIAaQBsAGkAdAB5AC0AdgAxAC4AYQBzAGQABgByAHAAZQBuAG4A bwBwAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABy AHAAZQBuAG4AbwBcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8A cwBvAGYAdABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABv AGYAIABpAHAAZgBpAHgALQBhAHAAcABsAGkAYwBhAGIAaQBsAGkAdAB5AC0AdgAxAC4AYQBzAGQA BgByAHAAZQBuAG4AbwBwAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0 AGkAbgBnAHMAXAByAHAAZQBuAG4AbwBcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0AGEA XABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAg AHMAYQB2AGUAIABvAGYAIABpAHAAZgBpAHgALQBhAHAAcABsAGkAYwBhAGIAaQBsAGkAdAB5AC0A dgAxAC4AYQBzAGQABgByAHAAZQBuAG4AbwBwAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBu AGQAIABTAGUAdAB0AGkAbgBnAHMAXAByAHAAZQBuAG4AbwBcAEEAcABwAGwAaQBjAGEAdABpAG8A bgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBj AG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABpAHAAZgBpAHgALQBhAHAAcABsAGkAYwBhAGIA aQBsAGkAdAB5AC0AdgAxAC4AYQBzAGQABgByAHAAZQBuAG4AbwBwAEMAOgBcAEQAbwBjAHUAbQBl AG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXAByAHAAZQBuAG4AbwBcAEEAcABwAGwA aQBjAGEAdABpAG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABB AHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABpAHAAZgBpAHgALQBhAHAA cABsAGkAYwBhAGIAaQBsAGkAdAB5AC0AdgAxAC4AYQBzAGQABgByAHAAZQBuAG4AbwBwAEMAOgBc AEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXAByAHAAZQBuAG4A bwBcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYAdABc AFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABpAHAA ZgBpAHgALQBhAHAAcABsAGkAYwBhAGIAaQBsAGkAdAB5AC0AdgAxAC4AYQBzAGQABgByAHAAZQBu AG4AbwAnAEQAOgBcAGkAcABmAGkAeAAtAGEAcABwAGwAaQBjAGEAYgBpAGwAaQB0AHkALQB2ADEA LQByAGUAdgBpAHMAaQBvAG4AMQAuAGQAbwBjAAYAcgBwAGUAbgBuAG8AJwBEADoAXABpAHAAZgBp AHgALQBhAHAAcABsAGkAYwBhAGIAaQBsAGkAdAB5AC0AdgAxAC0AcgBlAHYAaQBzAGkAbwBuADEA LgBkAG8AYwD/QAOAAQDRfwAA0X8AACzkTwQBAAEA0X8AAAAAAADRfwAAAAAAAAIQAAAAAAAAANd8 AABAAAAIAEAAAP//AgAAAAcAVQBuAGsAbgBvAHcAbgAGAHIAcABlAG4AbgBvAP//AgAIAAAAAAAA AAAAAAAAAAAAAAAAAAEA//8CAAAAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAYAAABHFpAB AAACAgYDBQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABS AG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0A YgBvAGwAAAAzJpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBs AAAARzWQAYAKAgIGCQQCBQgDBL8CAKD7/MdoEAAAAAAAAACfAAIAAAAAAE0AUwAgAE0AaQBuAGMA aABvAAAALf8z/yAADmYdZwAAPzWQAQAAAgcDCQICBQIEBId6ACAAAACACAAAAAAAAAD/AQAAAAAA AEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAAD0gkAEAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA AQAAAAAAAABBAHIAaQBhAGwALABCAG8AbABkAAAAIgAEAHGIiAgA8NACAABoAQAAAABkgmRGZIJk RgAAAAADAAAAAAB9EgAAZWkAAAEANQAAAAQAAxDgAAAAAAAAAAAAAAABAAEAAAABAAAAAAAAACQD APAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKUGwAe0ALQAgYEyMAAAEAAZAGQAAAAZAAAA boEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAACAAAAAAAAAAAAADKDEQDwEAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP//EgAAAAAAAAAOAEkAbgB0AGUAcgBuAGUAdAAgAEQAcgBhAGYAdAAAAAAAAAAGAHIAcABl AG4AbgBvAAYAcgBwAGUAbgBuAG8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZ MAAAAHQBAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAACwAAAABAAAALwAAAAFAAAAzAAAAAYAAADY AAAABwAAAOQAAAAIAAAA+AAAAAkAAAAIAQAAEgAAABQBAAAKAAAAMAEAAAwAAAA8AQAADQAAAEgB AAAOAAAAVAEAAA8AAABcAQAAEAAAAGQBAAATAAAAbAEAAAIAAADkBAAAHgAAAA8AAABJbnRlcm5l dCBEcmFmdAAAHgAAAAEAAAAAbnRlHgAAAAcAAABycGVubm8AdB4AAAABAAAAAHBlbh4AAAABAAAA AHBlbh4AAAALAAAATm9ybWFsLmRvdABhHgAAAAcAAABycGVubm8AZB4AAAACAAAAMwBlbh4AAAAT AAAATWljcm9zb2Z0IFdvcmQgOS4wAABAAAAAAAAAAAAAAABAAAAAAJiAymTlwQFAAAAAAJiAymTl wQEDAAAAAQAAAAMAAAB9EgAAAwAAAGVpAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD+/wAABQACAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAAD4AAAA DAAAAAEAAABoAAAADwAAAHAAAAAFAAAAfAAAAAYAAACEAAAAEQAAAIwAAAAXAAAAlAAAAAsAAACc AAAAEAAAAKQAAAATAAAArAAAABYAAAC0AAAADQAAALwAAAAMAAAA1wAAAAIAAADkBAAAHgAAAAEA AAAAAG4AAwAAAOAAAAADAAAANQAAAAMAAABugQAAAwAAAO0OCQALAAAAAAAAAAsAAAAAAAAACwAA AAAAAAALAAAAAAAAAB4QAAABAAAADwAAAEludGVybmV0IERyYWZ0AAwQAAACAAAAHgAAAAYAAABU aXRsZQADAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAA AAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAe AAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwA AAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAA ADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAA SQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABX AAAAWAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAAAGUA AABmAAAAZwAAAGgAAAD+////agAAAGsAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAAcwAA AHQAAAB1AAAAdgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAAAH0AAAB+AAAAfwAAAIAAAACBAAAA ggAAAIMAAACEAAAAhQAAAIYAAACHAAAAiAAAAIkAAACKAAAAiwAAAIwAAACNAAAAjgAAAI8AAACQ AAAAkQAAAJIAAACTAAAAlAAAAJUAAACWAAAAlwAAAJgAAACZAAAAmgAAAJsAAACcAAAA/v///54A AACfAAAAoAAAAKEAAACiAAAAowAAAKQAAAD+////pgAAAKcAAACoAAAAqQAAAKoAAACrAAAArAAA AP7////9/////f///7AAAAD+/////v////7///////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////1IAbwBv AHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAPAVtdxk5cEBsgAA AIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA4AAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABpAAAAG2YAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQUAAAD//////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAi0AAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4A ZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/ ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnQAAAAAQAAAAAAAABQBEAG8A YwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAA ADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClAAAA ABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAADwFbXcZOXBAfAVtdxk5cEBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA/v// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////wEA/v8DCgAA /////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1TV29y ZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------_=_NextPart_000_01C1E564.9D062340-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Apr 18 09:16:03 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04739 for ; Thu, 18 Apr 2002 09:16:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16yBS4-00077k-00 for ipfix-list@mil.doit.wisc.edu; Thu, 18 Apr 2002 07:55:52 -0500 Received: from h007.c001.snv.cp.net ([209.228.32.121] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16yBS2-00076t-00 for ipfix@net.doit.wisc.edu; Thu, 18 Apr 2002 07:55:50 -0500 Received: (cpmta 17554 invoked from network); 18 Apr 2002 05:55:18 -0700 Received: from 24.221.253.53 (HELO kcn) by smtp.register-admin.com (209.228.32.121) with SMTP; 18 Apr 2002 05:55:18 -0700 X-Sent: 18 Apr 2002 12:55:18 GMT Message-ID: <002f01c1e6d8$8358e4d0$850f880a@kcn> From: "K.C. Norseth" To: Subject: [ipfix] Fw: I-D ACTION:draft-ietf-ipfix-architecture-01.txt Date: Thu, 18 Apr 2002 06:56:52 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit In case no one saw this. K.C. ----- Original Message ----- From: To: Cc: Sent: Thursday, April 18, 2002 5:59 AM Subject: I-D ACTION:draft-ietf-ipfix-architecture-01.txt | A New Internet-Draft is available from the on-line Internet-Drafts directories. | This draft is a work item of the IP Flow Information Export Working Group of the IETF. | | Title : Architecture Model for IP Flow Information Export | Author(s) : K. Norseth, G. Sadasivan | Filename : draft-ietf-ipfix-architecture-01.txt | Pages : 22 | Date : 17-Apr-02 | | This memo defines the architecture, for the export of measured IP | flow information out of an IPFIX device to a collector, per the | requirements defined in [2]. | | A URL for this Internet-Draft is: | http://www.ietf.org/internet-drafts/draft-ietf-ipfix-architecture-01.txt | | To remove yourself from the IETF Announcement list, send a message to | ietf-announce-request with the word unsubscribe in the body of the message. | | Internet-Drafts are also available by anonymous FTP. Login with the username | "anonymous" and a password of your e-mail address. After logging in, | type "cd internet-drafts" and then | "get draft-ietf-ipfix-architecture-01.txt". | | A list of Internet-Drafts directories can be found in | http://www.ietf.org/shadow.html | or ftp://ftp.ietf.org/ietf/1shadow-sites.txt | | | Internet-Drafts can also be obtained by e-mail. | | Send a message to: | mailserv@ietf.org. | In the body type: | "FILE /internet-drafts/draft-ietf-ipfix-architecture-01.txt". | | NOTE: The mail server at ietf.org can return the document in | MIME-encoded form by using the "mpack" utility. To use this | feature, insert the command "ENCODING mime" before the "FILE" | command. To decode the response(s), you will need "munpack" or | a MIME-compliant mail reader. Different MIME-compliant mail readers | exhibit different behavior, especially when dealing with | "multipart" MIME messages (i.e. documents which have been split | up into multiple messages), so check your local documentation on | how to manipulate these messages. | | | Below is the data which will enable a MIME compliant mail reader | implementation to automatically retrieve the ASCII version of the | Internet-Draft. | -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Apr 22 19:26:43 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17788 for ; Mon, 22 Apr 2002 19:26:43 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16zmrj-0001u4-00 for ipfix-list@mil.doit.wisc.edu; Mon, 22 Apr 2002 18:04:59 -0500 Received: from mailhub.xacct.com ([204.253.100.25]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16zmrh-0001tY-00 for ipfix@net.doit.wisc.edu; Mon, 22 Apr 2002 18:04:57 -0500 Received: (qmail 32321 invoked from network); 22 Apr 2002 23:04:24 -0000 Received: from usmail.xacct.com (204.253.100.12) by mailhub.us.xacct.com with SMTP; 22 Apr 2002 23:04:23 -0000 Received: from Kevinz (inside.us.xacct.com [204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g3MN4n420172; Mon, 22 Apr 2002 16:04:49 -0700 Reply-To: From: "kevin.zhang" To: Cc: "K.C. Norseth" Subject: RE: [ipfix] Fw: I-D ACTION:draft-ietf-ipfix-architecture-01.txt Date: Mon, 22 Apr 2002 16:05:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <002f01c1e6d8$8358e4d0$850f880a@kcn> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id TAA17788 Hi All, I was reading the new architecture draft, and noticed that the author's addresses section was significantly modified (beyond editorial). I would like to know what's the decision process on this change, do we have any consensus from the contributors to the document? Thanks, Kevin > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of K.C. Norseth > Sent: Thursday, April 18, 2002 5:57 AM > To: ipfix@net.doit.wisc.edu > Subject: [ipfix] Fw: I-D ACTION:draft-ietf-ipfix-architecture-01.txt > > > In case no one saw this. > > K.C. > > ----- Original Message ----- > From: > To: > Cc: > Sent: Thursday, April 18, 2002 5:59 AM > Subject: I-D ACTION:draft-ietf-ipfix-architecture-01.txt > > > | A New Internet-Draft is available from the on-line Internet-Drafts > directories. > | This draft is a work item of the IP Flow Information Export > Working Group > of the IETF. > | > | Title : Architecture Model for IP Flow Information Export > | Author(s) : K. Norseth, G. Sadasivan > | Filename : draft-ietf-ipfix-architecture-01.txt > | Pages : 22 > | Date : 17-Apr-02 > | > | This memo defines the architecture, for the export of measured IP > | flow information out of an IPFIX device to a collector, per the > | requirements defined in [2]. > | > | A URL for this Internet-Draft is: > | http://www.ietf.org/internet-drafts/draft-ietf-ipfix-architecture-01.txt > | > | To remove yourself from the IETF Announcement list, send a message to > | ietf-announce-request with the word unsubscribe in the body of the > message. > | > | Internet-Drafts are also available by anonymous FTP. Login with the > username > | "anonymous" and a password of your e-mail address. After logging in, > | type "cd internet-drafts" and then > | "get draft-ietf-ipfix-architecture-01.txt". > | > | A list of Internet-Drafts directories can be found in > | http://www.ietf.org/shadow.html > | or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > | > | > | Internet-Drafts can also be obtained by e-mail. > | > | Send a message to: > | mailserv@ietf.org. > | In the body type: > | "FILE /internet-drafts/draft-ietf-ipfix-architecture-01.txt". > | > | NOTE: The mail server at ietf.org can return the document in > | MIME-encoded form by using the "mpack" utility. To use this > | feature, insert the command "ENCODING mime" before the "FILE" > | command. To decode the response(s), you will need "munpack" or > | a MIME-compliant mail reader. Different MIME-compliant mail readers > | exhibit different behavior, especially when dealing with > | "multipart" MIME messages (i.e. documents which have been split > | up into multiple messages), so check your local documentation on > | how to manipulate these messages. > | > | > | Below is the data which will enable a MIME compliant mail reader > | implementation to automatically retrieve the ASCII version of the > | Internet-Draft. > | > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ޖ[hfhzݢ++njwlk/zZyƠyI칻&ޙj:+vw""vvƲ칻&ފ,j܀bm*_ݢ++n܆+ From majordomo@mil.doit.wisc.edu Wed Apr 24 10:18:27 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08758 for ; Wed, 24 Apr 2002 10:18:26 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 170MtS-0000t8-00 for ipfix-list@mil.doit.wisc.edu; Wed, 24 Apr 2002 08:33:10 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.us.nortel.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 170MtQ-0000o7-00 for ipfix@net.doit.wisc.edu; Wed, 24 Apr 2002 08:33:08 -0500 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3ODWi504638; Wed, 24 Apr 2002 06:32:44 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2JXNB4PF>; Wed, 24 Apr 2002 06:32:35 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C020F0A95@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: kevin.zhang@xacct.com, ipfix@net.doit.wisc.edu Cc: "K.C. Norseth" Subject: RE: [ipfix] Fw: I-D ACTION:draft-ietf-ipfix-architecture-01.txt Date: Wed, 24 Apr 2002 06:32:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EB94.7CE88086" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1EB94.7CE88086 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by zsc3s004.us.nortel.com id g3ODWi504638 Content-Transfer-Encoding: quoted-printable There has been increasing scrutiny in the IESG with regard to "author overload" on RFCs. Please see the following RFC Editor's policy statement for detai= ls: http://www.rfc-editor.org/policy.html On the other hand, the same policy states "While there may be occasional exceptions, we suggest that the person (or few people) who WROTE the document be listed as the sole author(s). Others who contributed to developing the specification may be listed in an Acknowledgment section, = if that is appropriate. " I believe several people in the acknowledgment section can be include in = the ones that "wrote the document" Also there is provision for only one editor when there a significant numb= er of contributors, "When there are a number of significant contributors, th= ere is usually a single person tasked with integrating the results into a sin= gle document; that person may be listed as "Editor", with acknowledgments for the other contributors" regards, Reinaldo >-----Original Message----- >From: kevin.zhang [mailto:kevin.zhang@xacct.com] >Sent: Monday, April 22, 2002 4:05 PM >To: ipfix@net.doit.wisc.edu >Cc: K.C. Norseth >Subject: RE: [ipfix] Fw: I-D=20 >ACTION:draft-ietf-ipfix-architecture-01.txt > > >Hi All, > >I was reading the new architecture draft, and noticed that the=20 >author's addresses section was significantly modified (beyond=20 >editorial). I would like to know what's the decision process=20 >on this change, do we have any consensus from the contributors=20 >to the document? > >Thanks, > >Kevin > >=20 > >=20 > > > >> -----Original Message----- >> From: majordomo listserver=20 >[mailto:majordomo@mil.doit.wisc.edu]On Behalf >> Of K.C. Norseth >> Sent: Thursday, April 18, 2002 5:57 AM >> To: ipfix@net.doit.wisc.edu >> Subject: [ipfix] Fw: I-D ACTION:draft-ietf-ipfix-architecture-01.txt >>=20 >>=20 >> In case no one saw this. >>=20 >> K.C. >>=20 >> ----- Original Message ----- >> From: >> To: >> Cc: >> Sent: Thursday, April 18, 2002 5:59 AM >> Subject: I-D ACTION:draft-ietf-ipfix-architecture-01.txt >>=20 >>=20 >> | A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> | This draft is a work item of the IP Flow Information Export=20 >> Working Group >> of the IETF. >> | >> | Title : Architecture Model for IP Flow Information Export >> | Author(s) : K. Norseth, G. Sadasivan >> | Filename : draft-ietf-ipfix-architecture-01.txt >> | Pages : 22 >> | Date : 17-Apr-02 >> | >> | This memo defines the architecture, for the export of measured IP >> | flow information out of an IPFIX device to a collector, per the >> | requirements defined in [2]. >> | >> | A URL for this Internet-Draft is: >> |=20 >http://www.ietf.org/internet-drafts/draft-ietf-ipfix-architectu >re-01.txt >> | >> | To remove yourself from the IETF Announcement list, send a=20 >message to >> | ietf-announce-request with the word unsubscribe in the body of the >> message. >> | >> | Internet-Drafts are also available by anonymous FTP. Login with the >> username >> | "anonymous" and a password of your e-mail address. After=20 >logging in, >> | type "cd internet-drafts" and then >> | "get draft-ietf-ipfix-architecture-01.txt". >> | >> | A list of Internet-Drafts directories can be found in >> | http://www.ietf.org/shadow.html >> | or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> | >> | >> | Internet-Drafts can also be obtained by e-mail. >> | >> | Send a message to: >> | mailserv@ietf.org. >> | In the body type: >> | "FILE /internet-drafts/draft-ietf-ipfix-architecture-01.txt". >> | >> | NOTE: The mail server at ietf.org can return the document in >> | MIME-encoded form by using the "mpack" utility. To use this >> | feature, insert the command "ENCODING mime" before the "FILE" >> | command. To decode the response(s), you will need "munpack" or >> | a MIME-compliant mail reader. Different MIME-compliant=20 >mail readers >> | exhibit different behavior, especially when dealing with >> | "multipart" MIME messages (i.e. documents which have been split >> | up into multiple messages), so check your local documentation on >> | how to manipulate these messages. >> | >> | >> | Below is the data which will enable a MIME compliant mail reader >> | implementation to automatically retrieve the ASCII version of the >> | Internet-Draft. >> | >>=20 >>=20 >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in=20 >> message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive =20 >http://ipfix.doit.wisc.edu/archive/=1D=E9i(tm)=A8=A5=B6?sZS=DD=A2j'z=D7h= S=DC"=B1=C7=9D=B9=A9=DD=B1 =AC=A1zZbzg=AC=B1=A8=1En?rR{.n=C7+?=B7=A6j)m=A2f=A3=A2=B7hs?=DE=B5=DA"=B7= =08=ACq=E7njwlk+=A7=B2=E6=ECr=B8>z*_<=18=A7(tm)=EB,j=07>=A1=DCEUR =AD=C8b=BD=E8m=B6Y=FFS-=E2=C5=DA"=B7=08=ACq=E7n=FD=AA=DC?+=DE ------_=_NextPart_001_01C1EB94.7CE88086 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] Fw: I-D = ACTION:draft-ietf-ipfix-architecture-01.txt

There has been increasing scrutiny in the IESG with = regard to "author overload"
on RFCs. Please see the following RFC Editor's = policy statement for details:

http://www.rfc-editor.org/policy.html

On the other hand, the same policy states "While = there may be occasional exceptions, we suggest that the person (or few = people) who WROTE the document be listed as the sole author(s). Others = who contributed to developing the specification may be listed in an = Acknowledgment section, if that is appropriate. "

I believe several people in the acknowledgment = section can be include in the ones that "wrote the = document"

Also there is provision for only one editor when = there a significant number of contributors, "When there are a = number of significant contributors, there is usually a single person = tasked with integrating the results into a single document; that person = may be listed as "Editor", with acknowledgments for the other = contributors"

regards,

Reinaldo



>-----Original Message-----
>From: kevin.zhang [mailto:kevin.zhang@xacct.com]<= /FONT>
>Sent: Monday, April 22, 2002 4:05 PM
>To: ipfix@net.doit.wisc.edu
>Cc: K.C. Norseth
>Subject: RE: [ipfix] Fw: I-D
>ACTION:draft-ietf-ipfix-architecture-01.txt
>
>
>Hi All,
>
>I was reading the new architecture draft, and = noticed that the
>author's addresses section was significantly = modified (beyond
>editorial).  I would like to know what's = the decision process
>on this change, do we have any consensus from = the contributors
>to the document?
>
>Thanks,
>
>Kevin
>
>
>
>
>
>
>
>> -----Original Message-----
>> From: majordomo listserver
>[mailto:majordomo@mil.doit.wi= sc.edu]On Behalf
>> Of K.C. Norseth
>> Sent: Thursday, April 18, 2002 5:57 = AM
>> To: ipfix@net.doit.wisc.edu
>> Subject: [ipfix] Fw: I-D = ACTION:draft-ietf-ipfix-architecture-01.txt
>>
>>
>> In case no one saw this.
>>
>> K.C.
>>
>> ----- Original Message -----
>> From: = <Internet-Drafts@ietf.org>
>> To: <IETF-Announce:>
>> Cc: <ipfix@net.doit.wisc.edu>
>> Sent: Thursday, April 18, 2002 5:59 = AM
>> Subject: I-D = ACTION:draft-ietf-ipfix-architecture-01.txt
>>
>>
>> | A New Internet-Draft is available from = the on-line Internet-Drafts
>> directories.
>> | This draft is a work item of the IP Flow = Information Export
>> Working Group
>> of the IETF.
>> |
>> | Title : Architecture Model for IP Flow = Information Export
>> | Author(s) : K. Norseth, G. = Sadasivan
>> | Filename : = draft-ietf-ipfix-architecture-01.txt
>> | Pages : 22
>> | Date : 17-Apr-02
>> |
>> | This memo defines the architecture, for = the export of measured IP
>> | flow information out of an IPFIX device = to a collector, per the
>> | requirements defined in [2].
>> |
>> | A URL for this Internet-Draft is:
>> |
>http://www.ietf.org/internet-drafts/draft-ietf-ipfix-a= rchitectu
>re-01.txt
>> |
>> | To remove yourself from the IETF = Announcement list, send a
>message to
>> | ietf-announce-request with the word = unsubscribe in the body of the
>> message.
>> |
>> | Internet-Drafts are also available by = anonymous FTP. Login with the
>> username
>> | "anonymous" and a password of = your e-mail address. After
>logging in,
>> | type "cd internet-drafts" and = then
>> | "get = draft-ietf-ipfix-architecture-01.txt".
>> |
>> | A list of Internet-Drafts directories can = be found in
>> | http://www.ietf.org/shadow.html
>> | or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> |
>> |
>> | Internet-Drafts can also be obtained by = e-mail.
>> |
>> | Send a message to:
>> | mailserv@ietf.org.
>> | In the body type:
>> | "FILE = /internet-drafts/draft-ietf-ipfix-architecture-01.txt".
>> |
>> | NOTE: The mail server at ietf.org can = return the document in
>> | MIME-encoded form by using the = "mpack" utility.  To use this
>> | feature, insert the command = "ENCODING mime" before the "FILE"
>> | command.  To decode the response(s), = you will need "munpack" or
>> | a MIME-compliant mail reader.  = Different MIME-compliant
>mail readers
>> | exhibit different behavior, especially = when dealing with
>> | "multipart" MIME messages (i.e. = documents which have been split
>> | up into multiple messages), so check your = local documentation on
>> | how to manipulate these messages.
>> |
>> |
>> | Below is the data which will enable a = MIME compliant mail reader
>> | implementation to automatically retrieve = the ASCII version of the
>> | Internet-Draft.
>> |
>>
>>
>> --
>> = Help        mailto:majordomo@net.doit.wi= sc.edu and say "help" in
>> message body
>> Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
>> "unsubscribe ipfix" in message = body
>> Archive    
>http://ipfix.doit.wisc.edu/archive/=1D=E9i(tm)=A8=A5= =B6‰šŽŠ=DD=A2j'z=D7hŠ=DC"=B1=C7=9D=B9=A9=DD= =B1
=AC=A1zZbžg=AC=B1=A8=1En‡rR{.n=C7+‰=B7=A6j)m=A2= f=A3=A2=B7hš‰=DE=B5=DA"=B7=08=ACq=E7njwlk+=A7=B2=E6=ECr=B8= ›z*_‹=18=A7(tm)=EB,j=07›=A1=DC€=AD=C8b=BD=E8m=B6= Ÿ=FFŠ-=E2=C5=DA"=B7=08=ACq=E7n=FD=AA=DC†+=DE=

------_=_NextPart_001_01C1EB94.7CE88086-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Apr 29 22:04:22 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26402 for ; Mon, 29 Apr 2002 22:04:22 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 172MgW-0000Xy-00 for ipfix-list@mil.doit.wisc.edu; Mon, 29 Apr 2002 20:44:04 -0500 Received: from mailhub.xacct.com ([204.253.100.25]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 172MgV-0000XE-00 for ipfix@net.doit.wisc.edu; Mon, 29 Apr 2002 20:44:03 -0500 Received: (qmail 8168 invoked from network); 30 Apr 2002 01:43:29 -0000 Received: from usmail.xacct.com (204.253.100.12) by mailhub.us.xacct.com with SMTP; 30 Apr 2002 01:43:29 -0000 Received: from Kevinz (pcp820112pcs.nrockv01.md.comcast.net [68.49.52.62]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g3U1i2430549 for ; Mon, 29 Apr 2002 18:44:02 -0700 Reply-To: From: "kevin.zhang" To: Subject: [ipfix] IPFIX-architecture Section 5 Date: Mon, 29 Apr 2002 21:44:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <00dd01c1e4c7$6d1e6d60$850f880a@kcn> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA26402 Hi All, I have the following comments regarding section 5.1.2 and section 5.1.4 in draft-ietf-ipfix-architecture-01.txt. I quote from our charter, the IPFIX system MUST - " Ensure that the flow export system is reliable in that it will minimize the likelihood of flow data being lost due to resource constraints in the exporter or receiver and to accurately report such loss if it occurs." As minimizing the flow data loss is a primary goal, I believe the functionality specified at the export process and collector is not sufficient. I thus propose the following modifications - ------------------------- Original - 5.1.2. IPFIX Protocol on IPFIX Device (At Export Process) 1. Ability to detect loss of connectivity with the collector and trigger the appropriate action (eg. a switch over to an alternate collector.) 2. Optionally export flow records to multiple collectors. 3. Monitor control information/flow record export, detect any overload in the process of exporting. Modifications - 5.1.2. IPFIX Device (at Export Process) Functionality 1. Ability to detect loss of connectivity with the collector and trigger the appropriate actions (e.g. a switch over to an alternate collector) 2. Optionally export flow records to multiple collectors. 3. Optionally re-transmit flow records upon indications of flow record losses from the collector. 4. Monitor control information from the collector and export process, detect any overload conditions in the export process and/or the collector. ------------------------------------ ------------------------------------ Original - 5.1.4. IPFIX Protocol on Collector 1. Monitor the reception of export packets from IPFIX device. 2. Optionally notify the status and overload conditions to the IPFIX device. Modifications - 5.1.4. Collector Functionality 1. Receive and decode the flow records from the IPFIX devices. 2. Ability to indicate flow record losses to the exporting IPFIX device and/or IPFIX users. 3. Optionally notify the status and overload conditions to the IPFIX device. ----------------------------------------- Thanks, Kevin ޖ[hfhzݢ++njwlk/zZyƠyI칻&ޙj:+vw""vvƲ칻&ފ,j܀bm*_ݢ++n܆+ From majordomo@mil.doit.wisc.edu Mon Apr 29 22:04:34 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26415 for ; Mon, 29 Apr 2002 22:04:34 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 172MgW-0000Xx-00 for ipfix-list@mil.doit.wisc.edu; Mon, 29 Apr 2002 20:44:04 -0500 Received: from mailhub.xacct.com ([204.253.100.25]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 172MgU-0000XC-00 for ipfix@net.doit.wisc.edu; Mon, 29 Apr 2002 20:44:02 -0500 Received: (qmail 8163 invoked from network); 30 Apr 2002 01:43:29 -0000 Received: from usmail.xacct.com (204.253.100.12) by mailhub.us.xacct.com with SMTP; 30 Apr 2002 01:43:29 -0000 Received: from Kevinz (pcp820112pcs.nrockv01.md.comcast.net [68.49.52.62]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g3U1i1430546 for ; Mon, 29 Apr 2002 18:44:02 -0700 Reply-To: From: "kevin.zhang" To: Subject: [ipfix] Terminology - Control Stream, Data Stream Date: Mon, 29 Apr 2002 21:44:14 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA26415 Hi All, I was reading the architecture draft -01, and believed that our discussions regarding control information and flow record are not accurately captured by the current draft. Let me try to classify this issue one more time, and see if we can all agree on this going forward. First, I don't believe we need the terms "Control Stream" and "Data Stream" as they are redundant to the terms "Control Information" and "Flow Record". As they don't add any value to the document, let's remove them and define Control Information and Flow Record (or Flow Data) directly. Secondly, the "control information" is bi-directional and exchanged between the exporting process and collectors. It is possible for "control information" to be sent uni-directional from the exporting process to collectors, but this is one instance of the "control information" exchange. We can then enumerate what consists of "control information". I thus propose the following - * Control Information, Flow Record - The Control Information is exchanged between IPFIX end-points to facilitate the correct protocol operations and Flow Record encoding/decoding. It may include flow definitions and templates. - The Flow Record is exported from the IPFIX exporting process to IPFIX collectors. It consists of data records representing the flow definitions and properties. Thanks, Kevinޖ[hfhzݢ++njwlk/zZyƠyI칻&ޙj:+vw""vvƲ칻&ފ,j܀bm*_ݢ++n܆+ From majordomo@mil.doit.wisc.edu Mon Apr 29 22:36:55 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27720 for ; Mon, 29 Apr 2002 22:36:55 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 172NJx-0001Sp-00 for ipfix-list@mil.doit.wisc.edu; Mon, 29 Apr 2002 21:24:49 -0500 Received: from pool-162-83-253-134.ny5030.east.verizon.net ([162.83.253.134] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 172NJv-0001Sf-00 for ipfix@net.doit.wisc.edu; Mon, 29 Apr 2002 21:24:47 -0500 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id g3U2Okx07506; Mon, 29 Apr 2002 22:24:46 -0400 Reply-To: From: "Carter Bullard" To: , Subject: RE: [ipfix] IPFIX-architecture Section 5 Date: Mon, 29 Apr 2002 22:24:42 -0400 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A3A3@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660769E4@ptah.newyork.qosient.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Kevin, I would suggest one addition to your IPFIX device list, included below as item 5. Hope all is well, Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com > ------------------------- > Original - > 5.1.2. IPFIX Protocol on IPFIX Device (At Export Process) > > 1. Ability to detect loss of connectivity with the collector and > trigger the appropriate action (eg. a switch over to an > alternate collector.) > 2. Optionally export flow records to multiple collectors. > 3. Monitor control information/flow record export, detect any > overload in the process of exporting. > Modifications - > 5.1.2. IPFIX Device (at Export Process) Functionality > > 1. Ability to detect loss of connectivity with the collector > and trigger the appropriate actions (e.g. a switch over to an > alternate collector) > 2. Optionally export flow records to multiple collectors. > 3. Optionally re-transmit flow records upon indications of > flow record losses from the collector. > 4. Monitor control information from the collector and export > process, detect any overload conditions in the export process > and/or the collector. 5. Optionally store flow records while association with collector is lost. > ------------------------------------ > > ------------------------------------ > Original - > 5.1.4. IPFIX Protocol on Collector > > 1. Monitor the reception of export packets from IPFIX device. > 2. Optionally notify the status and overload conditions to the > IPFIX device. > > Modifications - > 5.1.4. Collector Functionality > 1. Receive and decode the flow records from the IPFIX devices. > 2. Ability to indicate flow record losses to the exporting > IPFIX device and/or IPFIX users. > 3. Optionally notify the status and overload conditions to > the IPFIX device. > ----------------------------------------- > > Thanks, > > Kevin -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Apr 30 11:39:46 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25580 for ; Tue, 30 Apr 2002 11:39:46 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 172ZNU-0005Dd-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Apr 2002 10:17:16 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 172ZNS-0005BL-00 for ipfix@net.doit.wisc.edu; Tue, 30 Apr 2002 10:17:14 -0500 Received: from cisco.com (bclaise-isdn-home.cisco.com [10.49.4.218]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA21853; Tue, 30 Apr 2002 17:16:40 +0200 (MET DST) Message-ID: <3CCEB556.EE069F72@cisco.com> Date: Tue, 30 Apr 2002 17:16:39 +0200 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: kevin.zhang@xacct.com CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX-architecture Section 5 References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by strange-brew.cisco.com id RAA21853 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA25580 Hi Kevin, > Hi All, > > I have the following comments regarding section 5.1.2 and section 5.1.4 in draft-ietf-ipfix-architecture-01.txt. > > I quote from our charter, the IPFIX system MUST - > " Ensure that the flow export system is reliable in that it will > minimize the likelihood of flow data being lost due to resource > constraints in the exporter or receiver and to accurately report > such loss if it occurs." > > As minimizing the flow data loss is a primary goal, I believe the functionality specified at the export process and collector is not sufficient. I thus propose the following modifications - > > ------------------------- > Original - > 5.1.2. IPFIX Protocol on IPFIX Device (At Export Process) > > 1. Ability to detect loss of connectivity with the collector and > trigger the appropriate action (eg. a switch over to an > alternate collector.) > 2. Optionally export flow records to multiple collectors. > 3. Monitor control information/flow record export, detect any > overload in the process of exporting. > Modifications - > 5.1.2. IPFIX Device (at Export Process) Functionality > > 1. Ability to detect loss of connectivity with the collector and trigger the appropriate actions (e.g. a switch over to an alternate collector) > 2. Optionally export flow records to multiple collectors. > 3. Optionally re-transmit flow records upon indications of flow record losses from the collector. I don't like too much the term "re-transmit". What if you don't have the flow records anymore? > > 4. Monitor control information from the collector and export process, detect any overload conditions in the export process and/or the collector. "Monitor control information from the collector and export process". I think this is confusing. We really want to monitor 2 things: - the control information - the export process And not the control information from the export process, as we could understand it from your sentence. I disagree with "the overload conditions on the collector", we are concentrating on the exporter From the requirements draft: 2.6. Collector The collector receives flow records from one or more export processes. The collector might process or store received flow record, but these actions are out of the scope of this document. > > ------------------------------------ > > ------------------------------------ > Original - > 5.1.4. IPFIX Protocol on Collector > > 1. Monitor the reception of export packets from IPFIX device. > 2. Optionally notify the status and overload conditions to the > IPFIX device. > > Modifications - > 5.1.4. Collector Functionality > 1. Receive and decode the flow records from the IPFIX devices. > 2. Ability to indicate flow record losses to the exporting IPFIX device and/or IPFIX users. Agreed. Regards, Benoit > > 3. Optionally notify the status and overload conditions to the IPFIX device. > ----------------------------------------- > > Thanks, > > Kevin > ޖ[hfhzݢ++njwlk/zZy yI칻&ޙj:+vw""vvƲ칻&ފ,j܀bm*_ݢ++n܆+ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Apr 30 14:23:48 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02580 for ; Tue, 30 Apr 2002 14:23:47 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 172bvP-00012b-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Apr 2002 13:00:27 -0500 Received: from mailhub.xacct.com ([204.253.100.25]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 172bvN-0000z2-00 for ipfix@net.doit.wisc.edu; Tue, 30 Apr 2002 13:00:25 -0500 Received: (qmail 28654 invoked from network); 30 Apr 2002 17:59:49 -0000 Received: from usmail.xacct.com (204.253.100.12) by mailhub.us.xacct.com with SMTP; 30 Apr 2002 17:59:49 -0000 Received: from Kevinz (slip-32-103-10-239.md.us.prserv.net [32.103.10.239]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g3UI0L409577; Tue, 30 Apr 2002 11:00:21 -0700 Reply-To: From: "kevin.zhang" To: "Benoit Claise" Cc: Subject: RE: [ipfix] IPFIX-architecture Section 5 Date: Tue, 30 Apr 2002 14:00:34 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3CCEB556.EE069F72@cisco.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id OAA02580 Hi Benoit, Please see my comments. > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Tuesday, April 30, 2002 11:17 AM > To: kevin.zhang@xacct.com > Cc: ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] IPFIX-architecture Section 5 > > > Hi Kevin, > > > > Hi All, > > > > I have the following comments regarding section 5.1.2 and > section 5.1.4 in draft-ietf-ipfix-architecture-01.txt. > > > > I quote from our charter, the IPFIX system MUST - > > " Ensure that the flow export system is reliable in that it will > > minimize the likelihood of flow data being lost due to resource > > constraints in the exporter or receiver and to accurately report > > such loss if it occurs." > > > > As minimizing the flow data loss is a primary goal, I believe > the functionality specified at the export process and collector > is not sufficient. I thus propose the following modifications - > > > > ------------------------- > > Original - > > 5.1.2. IPFIX Protocol on IPFIX Device (At Export Process) > > > > 1. Ability to detect loss of connectivity with the collector and > > trigger the appropriate action (eg. a switch over to an > > alternate collector.) > > 2. Optionally export flow records to multiple collectors. > > 3. Monitor control information/flow record export, detect any > > overload in the process of exporting. > > Modifications - > > 5.1.2. IPFIX Device (at Export Process) Functionality > > > > 1. Ability to detect loss of connectivity with the collector > and trigger the appropriate actions (e.g. a switch over to an > alternate collector) > > 2. Optionally export flow records to multiple collectors. > > 3. Optionally re-transmit flow records upon indications of > flow record losses from the collector. > > I don't like too much the term "re-transmit". > What if you don't have the flow records anymore? > The IPFIX protocol should support application level reliability as user desires. This is why I added "re-transmission" as an optional exporter functionality. My understanding of the IPFIX protocol is that we need to provide adequate mechansims that would allow different user requirements (e.g. reliability, redundancy, performance related considerations) being addressed. Whether these capabilities are invoked by the IPFIX users (applications using IPFIX protocol)would be implementation specific. > > > > 4. Monitor control information from the collector and export > process, detect any overload conditions in the export process > and/or the collector. > > "Monitor control information from the collector and export process". > I think this is confusing. We really want to monitor 2 things: > - the control information > - the export process I agree, this is acutally what I meant. How about changing it to "Monitor control information from the collector, monitor export process, detect ..." > And not the control information from the export process, as we > could understand it from your sentence. > > I disagree with "the overload conditions on the collector", we > are concentrating on the exporter IPFIX protocol is split between exporter and collectors. If the collector can indicate the overload condition, the exporter should detect it and take actions just as overloading at the export process. We are addressing an IPFIX system, and try to "Minimize" losses as charter outlined. Detection of collector overloading is one way of minimizing losses, as there's no point to sending to a overloaded collector, where data is dropped; instead, fail-over to a redundant collector would be a much better approach. > >From the requirements draft: > 2.6. Collector > > The collector receives flow records from one or more export > processes. The collector might process or store received flow > record, but these actions are out of the scope of this document. > > > > > ------------------------------------ > > > > ------------------------------------ > > Original - > > 5.1.4. IPFIX Protocol on Collector > > > > 1. Monitor the reception of export packets from IPFIX device. > > 2. Optionally notify the status and overload conditions to the > > IPFIX device. > > > > Modifications - > > 5.1.4. Collector Functionality > > 1. Receive and decode the flow records from the IPFIX devices. > > 2. Ability to indicate flow record losses to the exporting > IPFIX device and/or IPFIX users. > > Agreed. > > Regards, Benoit > > > > > 3. Optionally notify the status and overload conditions to the > IPFIX device. > > ----------------------------------------- > > > > Thanks, > > > > Kevin > > ޖ[hfhzݢ++njwlk/zZy > yI칻&ޙj:+vw""vvƲ칻&ފ,j܀ > bm*_ݢ++n܆+ޖ[hfhzݢ++njwlk/zZyƠyI칻&ޙj:+vw""vvƲ칻&ފ,j܀bm*_ݢ++n܆+