Subject: Re: [ipfix-info] "post" Information Elements: "can not necessarily be observed at the Observation Point of this flow"

From: Juergen Quittek <[email-masked]>
Date: Thu, 21 Jul 2005 21:35:55 +0200

Hi Benoit,

Thanks for the detailed reply.
Please find comments in line.

--On 7/20/2005 2:01 PM +0200 Benoit Claise wrote:

> Juergen and all,
>
> Thanks for the detailed email. It will ease the discussion.
>
> You see this pre and post prefix problem from the point of view of the
> observation point only.
> This is fine because we have in RFC 3917:
>
>    "All measurements must be conducted from the point of view of the
>    observation point."
> Btw, I think that this statement should appear in [IPFIX-ARCH]. I took me
> quite some time to locate this sentence as I thought it was in one of
> current draft already.
> However, I see the problem differently: before and after the packet
> treatment at the observation point.

I think here is already the point where we are not in sync.
I do not expect the packet treatment to necessarily happen at the
observation point only.

Let's take the multicast daemon as an example that is already supported by
NetFlow version 9.  If you locate your observation point (or observation
domain) at a routers line card, then the multicast daemon running on the
core processor of your router is not in the observation domain.  However,
it would still be nice to report the number of multicast packets and octets
after packet treatment by the multicast daemon.

> I will show that this view exclude the solution 1, leads to the natural
> selection of slightly modified solution 2, i.e. solution 3
>
> Remember the flow definition, in which the packet treatment is clearly mentioned:
>
>       A Flow is defined as a set of IP packets passing an Observation
>       Point 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 packet header field (e.g. destination IP address),
>           transport header field (e.g. destination port number), or
>           application header field (e.g.  RTP header fields RTP-HDRF
>           [5].
>
>       2.  One or more characteristics of the packet itself (e.g. number
>           of MPLS labels)
>
>       3.  One or more fields derived from packet treatment (e.g. next
>           hop IP address, output interface)
> I see the "packet treatment" as the typical function of a middlebox.

Agreed.

> The definition could have been extended with for example the modified DSCP value.
>
> So let me propose the solution 3 (let me refer to "solution 3" later on in
> this email):
>  all flow properties that are exported represent the flow as it was
>  when entering the IPFIX device except, if their name has the
>  prefix "post".  Information elements without the prefix would
>  describe flows characteristics of incoming packets and information
>  elements with the "post" prefix would describe flows characteristics
>  after packet treatment.

If I understand correctly, then solution 2 maps with/without prefix to
incoming and outgoing with respect to the IPFIX device while solution 3
maps with/without prefix to incoming and outgoing packets with respect
to the observation domain. Right?

> See inline.
>
>
>
> 	Dear all,
> 	
> 	Here is the problem description for the "pre" and "post" prefixes
> 	that I promised last weekend.
> 	
> 	I am sorry for the delay in sending this.  It is caused by my
> 	inability to explain the issue briefly.  Please excuse that this
> 	inability also is the reason why you have to read an awfully long
> 	message in order to help solving the problem.
> 	
> 	
> 	Let me start with a short introduction to the problem we have with
> 	middleboxes and other boxes that change flow properties:
> 	
> 	Some middleboxes change properties of a flow.  For example, a DiffServ
> 	marker changes the value of the IPv4 TOS field, a network address
> 	translator changes source or destination IP addresses, and a traffic
> 	shaper changes the number of packets and bytes of a flow.
> 	
> 	Consequently, on one side of a middlebox a traffic flow might have
> 	properties that are different to its properties on the other side
> 	of the middlebox.
> 	
> 	Now, if an observation point stretches so far that it includes both
> 	sides of the middlebox, we run into ambiguities.  In such a case,
> 	there are two different values for packet count, byte count, DSCP,
> 	source IP address, etc. to be observed at the observation point.
> 	Which values should we export in such a situation?
> 	
> 	We discussed this issue at our meeting in Seoul where Martin gave
> 	a presentation that you can find in the proceedings:
> 	<http://www.ietf.org/proceedings/04mar/slides/ipfix-3/index.html> <http://www.ietf.org/proceedings/04mar/slides/ipfix-3/index.html>
> 	Also a draft discussing it is available in the archive:
> 	<http://www.watersprings.org/pub/id/draft-quittek-ipfix-middlebox-00.txt> <http://www.watersprings.org/pub/id/draft-quittek-ipfix-middlebox-00.txt>
> 	
> 	I see two solutions for this problem and the discussion we need to
> 	have is about selecting one of them or another solution suggested by
> 	someone else.
> 	
> 	
> 	Solution 1
> 	 The recommendation that was made at the meeting and in the (already
> 	 expired) draft was to avoid these ambiguities by avoiding to have an
> 	 observation point that includes both sides of a middlebox.
> 	
>
> There is no ambiguities if you apply solution 3:
>
>
>
> 	 This solves the ambiguity problem. If it is clearly specified on which
> 	 side of a middlebox we have our observation point, then we know which
> 	 observed values to export.
> 	
> 	 However, sometimes it might be very useful to ALSO export values from
> 	 the other side of the middlebox.  These would be values that were not
> 	 necessarily derived from direct observation of packets, but by other
> 	 means available at the IPFIX device.
> 	
>
> I would say that it's not only useful, but it's a requirement.
> If you don't allow to export after treatment I.E., you run into problems such as:
> - exporting two records, from the ingress point and the egress observation points
> of your middlebox

If I have one metering process running on the ingress line card metering incoming
traffic and another independent one on the egress line card metering outgoing traffic,
then I would expect receiving two records for the same flow.

> - trying to combine the records, to match the initial flow. You're going to tell
> me that we could use the flow keys, but we don't always want to export the flow keys.
> Alternatively, we could use a flow ID, but this becomes way too complex.
>
>
>
>
> 	 Let's take a multicast daemon as an the example.  A multicast daemon
> 	 is not necessarily a middlebox, but it causes the same problem.
> 	 The daemon might be able to provide statistics on how many packets
> 	 it sent out for a certain multicast address.
> 	
> 	 If now our observation domain is restricted to the incoming traffic
> 	 at a single network interface at the IPFIX device, then we will
> 	 observe only the incoming multicast flow.  Still, it would be nice
> 	 to report for this flow the number of outgoing multicast packets
> 	 and octets.
> 	
> 	 NetFlow version 9 supports this by fields MUL_DST_PKTS
> 	 and MUL_DST_BYTES.  In the IPFIX info model they are called
> 	 postMCastPacketDeltaCount and postMCastOctetDeltaCount.
> 	
> 	 Note these objects report something that can not (necessarily)
> 	 be observed at the flow's observation point. The info model
> 	 elements have the prefix 'post' in order to indicate the fact
> 	 that these values do not necessarily result from an actual
> 	 observation. In this case they result from the reporting of
> 	 the multicast daemon.
> 	
>
> If you apply solution 3, it's up to the metering process at the observation
> point to evaluate whether or not he can report any "post" information.
> All routers/switches/middlebox will have a different architecture (one metering
> process per interface, per combination of interfaces, per line card, per router,
> etc...) so the only solution is to trust the metering process based on its
> capabilities. Is the metering process able to report some after packet treatment info?

One of the advantages of solution 1 is that what the metering process observes
directly is always without prefix, may it be incoming, outgoing, before or after
packet treatment.  If the metering process does not know about any (potentially
present) middleboxes then it always reports correctly if it reports what it sees
without prefix.  However, if it is aware of a middlebox, it may report how packets
look like on the other side by using the "pre" or "post" prefix.

> 	 As second example we can look at a DiffServ packet marker. It
> 	 changes the DSCP value of packets.  Following the approach of
> 	 solution 1, the location of the observation point should be
> 	 clearly specified to be at one or the other side of the marker.
> 	 There it observes the DSCP value that is reported by information
> 	 element classOfServiceIPv4 or classOfServiceIPv6.
> 	
> 	 Also here, scenarios can easily be found for which it is desirable
> 	 to report also the DSCP value that the flow has on the other side
> 	 of the marker, that is not covered by the observation point.
> 	 This is supported by NetFlow version 9 with the DST_TOS field and
> 	 in our information model by the elements postClassOfServiceIPv4
> 	 and postClassOfServiceIPv6.  As you see from the prefix of their
> 	 name, we can only use them if the observation point is located
> 	 on the path of the packet before it passes the marker.  If the
> 	 observation point would be located somewhere on the path after
> 	 the marker, we would need a different prefix for reporting from
> 	 the other side.
>
> Not really. Remember "All measurements must be conducted from the point of
> view of the observation point."
> So the observation point is not supposed to know that there is a previous
> observation point in the path.
> From the observation point point of view, it must report what is seen.
> Hence no "pre" prefixes are needed.

I think treating "pre" and "post" as symmetric prefixes is a feasible approach.

> Next question: is there any packet treatment at this observation point?

For solution 1 there is NEVER packet treatment AT an observation point.
The observation point is a single 'point' in the network where packets
pass by.  Particularly, it does not include a middlebox function.

> If no, we don't export any "post" prefix I.E. If yes, and if we can
> report the values, we export some "post" prefix I.E.

Repeating the example I used somewhere above:
Let's assume that our observation domain (that is reported in the IPFIX
message header) is a single line card.

Now we want to report MUL_DST_PKTS / postMCastPacketDeltaCount:

  - If we apply solution 2 or 3 strictly, then we cannot report
    them if the multicast daemon is not running on the line card.

  - But let's assume we can make this information available by
    exchanging information with the multicast daemon.
    Which observation domain would we report?
    Just report the line card this would conflict with solutions 2 and 3.
    But reporting the line card and the core processor would also wrong,
    because we do not observe all packets passing the core (or at least
    the multicast daemon. We just report packets that originate at the
    observed line card AND pass the multicast daemon.

> 	The current version of the info model suggests
> 	 prefix "pre" for this case, for example, "preClassOfServiceIPv4".
> 	 We do not have any instance of an information element with prefix
> 	 "pre" in the current version of our model, because common practice
> 	 is measuring at the incoming interface of a router.
> 	
>
> The solution 3 would also apply if you would monitor traffic at different
> points in the forwarding path of your device.
>
>
> 	Still, we
> 	 would need to add them at some time in the future if we follow
> 	 solution one.  Please not that also for the 'post' prefix only a
> 	 few instances are present.  We clearly expect to need more "post"
> 	 elements if we start having IPFIX implementations on network
> 	 address translators (postsourceIPv4Address, postTransportPort,
> 	 etc.).
> 	
> 	
> 	Solution 2
> 	 The other way of solving the ambiguities is declaring that all
> 	 flow properties that are exported represent the flow as it was
> 	 when entering the IPFIX device except, if their name has the
> 	 prefix "post".  Information elements without the prefix would
> 	 describe flows of incoming packets and elements with that
> 	 prefix would describe flows of outgoing packets.
> 	
>
> Note that, in solution 3, I changed outgoing packets by "after packet treatment"
>
>
>
> 	 In case of the multicast daemon, the packetDeltaCount would be
> 	 the number of incoming packets and the postMCastPacketDeltaCount
> 	 would be the number of outgoing multicast packets.
> 	
>
> Yes.
>
>
>
> 	 For the packet marker, classOfServiceIPv4 would deliver the value
> 	 of the DSCP before marking and preClassOfServiceIPv4 would deliver
> 	 the value after marking.
> 	
>
> Typo -> postClassOfServiceIPv4

Thanks.

> 	 This solution allows a more relaxed specification of the
> 	 observation point.  It may be the entire device.
>
> Exactly, this is a great advantage.
>
>
> 	Ambiguities
> 	 are avoided for this case, because every element is marked to
> 	 concern either incoming or outgoing traffic.
> 	
> 	
> 	Discussion
> 	 {Please note that I am biases and have a preference for solution 1.
> 	  Please contribute arguments for solution 2 or against solution 1
> 	  that are missing in the lists below because I am too ignorant to
> 	  see them.}
> 	
>
> Advantage of "solution 3"
> - the concept is simpler
> - we only need one prefix
>
> As solution 2 and 3 are almost similar, let me reply to the
> "disadvantage of solution 2" section
>
>
>
> 	 Advantages of solution 2:
> 	 - the concept is simpler.
> 	 - We only need one prefix.
> 	
> 	 Disadvantages of solution 2:
> 	 - The concept is simple but not always clear.
> 	   What about traffic observed at a network interface card in
> 	   promiscuous mode. This traffic would be neither incoming nor
> 	   outgoing.
> 	
>
> I don't see a problem, neither with solution 2 or solution 3.
> The NIC is the observation point, and

The problem is with solution 2, not with 3.

>    "All measurements must be conducted from the point of view of the
>    observation point."
> So the traffic which is entering the observation point is considered as as incoming.
> With solution 3, there is no packet treatment, so no "post" I.E.s are exported.
> With solution 2, there is no outgoing packets, so no "post" I.E.s are exported.
>
> 	 - A generic flow meter using libpcap typically observes incoming
> 	   traffic as well as outgoing traffic.  This meter would need to
> 	   check for all packets if they are incoming or outgoing (probably
> 	   by checking the MAC addresses) and use elements without prefix
> 	   for reporting the incoming packets and elements with "post"
> 	   prefix for reporting the outgoing traffic.
> 	
>
> Is this a drawback? All the traffic entering the observation point is metered.
> " The observation point is a location in the network where IP packets can be observed."
> I don't consider this as a drawback for solution 2 and 3
>
>
> 	 - We must define an information element with a "post" prefix for
> 	   almost all the non-post elements in sections
> 	     - 5.3 IP Header Fields (31 elements)
> 	     - 5.4 Transport Header Fields (16 elements),
> 	     - 5.5  Sub-IP Header Fields (19 elements)
> 	     - 5.7  Min/Max Flow Properties (11 elements)
> 	     - 5.9  Per-Flow Counters (12 elements)
> 	   currently, only 13 of them are defined.
> 	
>
> Yes, this is true for solution 2 and solution 3.
> What we agreed in the past is that people will request those as they need them.
>
>
> 	 - We cannot report bidirectional flows anymore, if our observation
> 	   point does not cover all interfaces.  If we measure at a single
> 	   interface, then we cannot aggregate the packet and octet counters
> 	   of a bi-directional flow, because for one direction we must use
> 	   the non-prefix counter and for the other direction we must use
> 	   the prefix counter.
> 	
>
> True for solution 2 and solution 3 but I don't see how it's possible with the solution 1

with solution 1, the observation point is a single point not including any
packet treatment.  All packets that are directly observed there are reported
without prefix.  Hence you can aggregate the counters of packets that pass
the observation point in different directions.

> 	 Advantages of solution 1:
> 	 - The concept is clean: no prefix for actually measured traffic
> 	   prefixes for flow properties that are obtained by other means.
> 	 - We need prefixes only if middleboxes are involved and supported
> 	   by the metering process.  We do not need prefixes in all other
> 	   cases, particularly not for for simple bidirectional measurements
> 	   or for unidirectional measurements of outgoing traffic.
> 	
>
> This is a big drawback.
> If I have a router forwarding traffic, I export a template with no-prefix.
> My monitoring application is happy.
> Now, the operational team decides to add some DSCP re-marking capabilities
> in the router. Now my templates export the "pre" I.E. for the same information.

No. Before and after only packets observed at the observation point are
reported independent of the presence of a middlebox.  However, if the metering
process has the appropriate capability, it can also report from beyond the
middlebox using "pre" or "post" depending on the traffic direction.

> Not sure my monitoring application will be happy.
> Basically, depending on the (middlebox) features enabled on the router,
> I will export different I.E.s. This solution doesn't work.

This problem only exists for solution 2.
I thin we can eliminate this one from further discussion.

> 	 Disadvantages of solution 2:
> 	
>
> Typo -> Disadvantages of solution 1:

Thanks.

> 	 - We need two prefixes
> 	
>
> Basically we need "pre", "post" and no prefix. So we have 3 series of I.E.s

Yes.

> 	 - We might end up with a higher total number of elements
> 	
>
> - Another disadvantage. The choice of these pre, post, no prefix series of I.E.s
> depend so much on the architecture of the device and that you will have
> interoperability problem first of all, and the collector will have to know
> the architecture of the exporter in order to benefit from the exported I.E.s

Well, you mainly will have to precisely identify your observation point.
Then there is no more dependency on the architecture.

> The [IPFIX-INFO] draft has always been (almost) in line with solution 3
> until the recent addition in the version 8.

I think the same holds for solution 1.  Just the parts to which the "(almost)"
refers are different.

Cheers,

   Juergen

> Regards, Benoit.
> 	Thanks,
> 	   Juergen

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

---

From: Benoit Claise <[email-masked]>
Date: Mon, 25 Jul 2005 17:28:31 +0200

Hi Juergen,

See more in line.

> I do not expect the packet treatment to necessarily happen at the

I agree we are not in sync. ;)
You wrote "I do not expect ...". This is the issue: you expect what the 
observation point will be ... and from there, you try to deduce the 
correct behavior for pre and post.
 From the observation point definition, we see that we can't assume 
anything about the observation.

   An Observation Point is a location in the network where IP packets 
   can be observed.  Examples include: 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. 

> after packet treatment by the multicast daemon.

Again you assume things: in this case that the multicast daemon running 
on the core processor.
If you take into account "All measurements must be conducted from the 
point of view of the observation point.", then it's the observation 
point will report what he thinks he's right after packet treatment (this 
is solution 3 below). BTW, there is nothing more we can do from the 
observation point of view.

> to the observation domain. Right?

No. Let me rephrase this.
 all flow properties that are exported represent the flow as it was
 when entering the _observation point_ except, if their name has the
 prefix "post".  Information elements without the prefix would
 describe flows characteristics of incoming packets and information
 elements with the "post" prefix would describe flows characteristics
 after packet treatment, _from an observation point of view_.

>>     <http://www.ietf.org/proceedings/04mar/slides/ipfix-3/index.html> 
>> <http://www.ietf.org/proceedings/04mar/slides/ipfix-3/index.html>
>>     <http://www.watersprings.org/pub/id/draft-quittek-ipfix-middlebox-00.txt> 
>> <http://www.watersprings.org/pub/id/draft-quittek-ipfix-middlebox-00.txt> 
>>
>>     

In this case, you're right!
I was thinking of a simple router without line cards (so a single 
observation domain). In this case, if we don't want to export to flow 
records, we must export after packet treatment.

> look like on the other side by using the "pre" or "post" prefix.

As I wrote below, this is not an advantage but a drawback [drawback]

> pass by.  Particularly, it does not include a middlebox function.

Remember the multiple examples of the observation point...

>    them if the multicast daemon is not running on the line card.

Right.

>    observed line card AND pass the multicast daemon.

I personally think that you make the situation more complicated than 
it's really is by always referring to the multicast example.
The logic in your example would tell us to use the observation domain as 
being the incoming line card.

> The problem is with solution 2, not with 3.

I don't see a problem with solution 2 regarding this issue.

> packet treatment.  

What about the different examples of an observation point? Ex: line 
card, router?

> All packets that are directly observed there are reported

[drawback]. Whatever the direction, whatever the pre or post, my point 
and the drawback I see are that the template will change:
- when I insert/remove a middlebox function
- if I don't want to duplicate the information.

>> Basically we need "pre", "post" and no prefix. So we have 3 series of 

This is a major drawback according to me.

> Well, you mainly will have to precisely identify your observation point.

... according to the architecture of the box.
Let me repeat what I wrote: collector will have to know the architecture 
of the exporter in order to benefit from the exported I.E.s
Again, this is a major drawback.

I'm afraid that with solution 2, we try to build the perfect solution by 
specifying the observation point, the direction, the pre/post/no_prefix, so
- the counters when entering the first the line card,
- the counters when leaving the first line card without middlebox,
- the counters when leaving the first line card with middlebox,
- the counters when entering the second line card,
- the counters when leaving the second line card without middlebox
- the counters when leaving the second line card with middlebox
This is done at the expense of an overloaded information model

What we mainly need is something similar to NetFlow:
- the counters when entering the first the line card,  (no prefix)
- potentially the counters when leaving the second line card  (post 
prefix, direction = egress)
AND if the router is not composed of line card, i.e. a single 
observation domain:
- the counters when entering the observation point, (no prefix)
- potentially the counters after packet treatment (post prefix, 
direction = egress)

> I think the same holds for solution 1.  Just the parts to which the 

Note quite. The "pre" prefix was never introduced before.

Regards, Benoit.

---

From: Sven Anderson <[email-masked]>
Date: Mon, 25 Jul 2005 18:23:33 +0200

Hello everybody,

Juergen Quittek schrieb:

 > I think here is already the point where we are not in sync. I do not
 > expect the packet treatment to necessarily happen at the observation
 > point only.

here's my point of view:

To be honest, both solutions don't look very clean to me. ;-)

It starts with the definition of Observation Points: "Note [...] that one 
Observation Point may be a superset of several other Observation Points". 
This implicates that _every_ field is always ambiguous, because it could 
be different at each of the atomic Observation Points. It won't help to 
split them up in post and pre Fields, as there could be even more than two 
states for the same Field. It would be cleaner, if every Field is bound to 
exactly one atomic Observation Point, or better to exactly one packet 
state. That is even true for the counter Fields, think of packet 
fragmentation for instance.

Then, what you obviously want, is the possibility to define Flows with 
properties, that derive from the same packet but at _different_ atomic 
Observation Points (e.g. before and after the NAT process), or more 
general, at different states of the packets. To archieve this, the 
Metering Process has to track the packets in his Observation Domain.

Example: In our network we have an VPN relay, which is a node that 
reencapsulates packets from e.g. OpenVPN to CIPE and vice versa. On this 
node it would be interesting to define a flow by: src/dst ip addresses at 
incoming interface, src/dst ip addresses and ports of the encapsulated ip 
header, src/dst ip address at outgoing interface. The flow should report 
the size of the packet at the incoming AND outgoing interface. Incoming 
and outgoing interface is here the same physical interface (eth0) over 
which the packet is traveling twice at different states. Of course, it 
leads to the philosophical question, after how much treatment a packet is 
still the same packet. But anyway, then I call these packets, which derive 
from each other, linked packets, and I want to define Flows by properties 
of these linked packets.

An easy way to allow this, would be to allow that the same Field can 
appear more then one time in a Template (is this forbidden right now, by 
the way?). But this is ugly, as you cannot see, which Field belongs to 
which packet state. So I would suppose a solution, where you can group the 
Fields somehow, for example that a basic Template can hold each Field only 
once, but you can define combined Templates, which consist of a list of 
basic Templates. That way you have a flexible way to report Flows that 
span over several (not only two, like the pre/post approach!) packet 
states, and that's all this pre/post discussion is about, right?

Then you also don't need in and out counter or ingress/egress interface 
IEs. Just one IE is enough, and if the Field is in the first or last 
Template of the combined Template tells you, if it represents the incoming 
or outgoing packet state respectively.

So I would vote for a more flexible and cleaner solution, without any 
pre/post prefixes.

Sorry that I come up with this so late, as it sounds like a bigger change, 
but I read this list as recently as I started a Ph.D. project about IPv6 
monitoring 3 months ago.

BTW.: In IPFIX-ARCH at 6.2 you find: "A Flow Record can be better analyzed 
if the Observation Point from which it was measured is known. As such it 
is recommended that IPFIX Devices send this information to Collectors."
Is there an IE to report this, or how should it work? As not the 
Observation Points but only the Observation Domains have an unique ID.

Cheers,

Sven

-- 
Sven Anderson
Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de
Georg-August-Universitaet Goettingen
Lotzestr. 16-18, 37083 Goettingen, Germany

---

From: Sven Anderson <[email-masked]>
Date: Tue, 26 Jul 2005 10:32:26 +0200

Hi Benoit,

> point will report what he thinks he's right after packet treatment (this 
                             ^^^^^^
> observation point of view.

I don't understand why you write "thinks". Either the treatment happens
_inside_ of an observation "point" (a strange terminology in this case, as
a point has no dimension, but as you allow a point to be a group of
points, it's possible), then it _knows_ what the packet looks like after,
or it happens after the observation point, then pre and post is the same,
whatever happens after.

>  after packet treatment, _from an observation point of view_.

Ok, maybe now I get it, you are referring to the borders of the device? So
_if_ there is a post field, then the non-post/post field refers to how the
observation point guesses the packet looked like when entering/leaving the
device, and the real observed data is not necessarily reported? Do you
mean that? Then the semantics of a field depends on the existence of
another field... I'm not sure if I like that... ;-)

Cheers,

Sven