[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Packet Selectors and Packet Information
> Should these topics be separated into 2 documents, or combined into 1
> (as the charter suggests)?
That sounds like a good idea -- the two issues are largely orthogonal.
If either one gets complicated, as they are likely to do, it is
appealing to separate them.
> b) What specific stateless packet selectors are needed?
Here's a simple strawman that probably isn't enough but could get the
ball rolling -- the standard 5-tuple scheme of matching on source and
destination prefixes, protocol, and port numbers, with "don't cares"
allowed for any of the fields (or any of the suffix bits in the source
and destination IP addresses). This 5-tuple representation (used also
for ACLs, packet classification for diff-serv, etc.) and, as such, we
could borrow from previous work on specifying the selectors, and on
configuration languages for specifying them.
Now, you could imagine specifying these kinds of selectors on a per
interface basis -- that is, a selector per psamp device, so if a
router has one or more psamp selector/sampler devices per interface,
they could each have different selector configurations.
Okay, so what's missing here... I've ignored MAC headers, VLAN, MPLS,
> Packet Information Issues:
I think we'd probably want two types of information
* information taken directly from the packet
- select IP and TCP/UDP header fields (and perhaps MAC, VLAN,
MPLS, tunnel, etc. headers, if needed)
* information derived locally as the packet is handled
- timestamp, longest matching prefix (on dest address, and
perhaps on source address if available), current interface,
We can probably borrow from other places here, like IPFiX and the work
vendors have done in defining flow and packet measurement formats.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.