Re: PSAMP: ipHeaderPacketSection and mplsLabelStackSection

[Andrew Johnson <andrjohn@cisco.com>]

Hi all

Falko Dressler wrote:
> Paul,
>
> this is indeed a difficult issue. At the first look, I was about saying
> "yes, 1b) is the best solution because it provides the highest
> flexibility". Nevertheless, I fear that many applications will derrive
> that allow to monitor packet payload but do not offer to analyze the
> packet header, i.e. such monitors are just "remote-pcap-devices". This
> is quite fine but makes most of PSAMP functionality (IEs) unnecessary.

I agree that 1b is the obvious choice, for the following reasons:

Firstly a PSAMP device offering the ipHeaderPacketSection will not have
to understand how to parse the IP header(s) making the implementation
easier and faster.

Secondly, most people who are using this IE will want to capture all or
part of the TCP/UDP header in order to retrieve the ports etc. and 1b
will allow all this information to be gathered in a single neat packet
section.


On a related note I think we should clearly state that the
ipPayloadPacketSection starts after the IPv6 extension headers to
give consistency between its use for IPv4 and IPv6 packets.

regards

Andrew


> 1a) is maybe too hard and 2) says "nothing"
>
> so may final answer is either 2) or we need to elaborate a 1c)
>
> Cheers,
> Falko
>
> Paul Aitken wrote:
> > Dear psampers,
> >
> > We have a new open issue in PSAMP-INFO:
> >
> >   Should the ipHeaderPacketSection and mplsLabelStackSection also
> >   report payload contents if the specified section length is longer
> >   than the IP header or stack size, respectively?
> >
> >
> > ipHeaderPacketSection is currently defined as:
> >
> >       This information element carries a series of octets from the start
> >       of the IP header of a sampled packet.
> >
> >
> > mplsLabelStackSection is currently defined as:
> >
> >       This information element carries the first n octets from the MPLS
> >       label stack of a sampled packet.
> >
> >
> > Potential resolutions include:
> >
> > (1) We define the behaviour when the requested ipHeaderPacketSection
> > or mplsLabelStackSectionsection size is larger than the actual amount of
> > IP header / label stack data available.
> >
> >   (1a) We define that only IP header / label stack octets are included.
> >
> >   (1b) We define that the section contains a series of octets starting
> >        from the beginning of the IP header / label stack and continuing
> >        through the payload up to the limit of the available data.
> >
> > (2) We say nothing, and leave it as implimentation defined behaviour.
> >
> >
> > I believe that allowing these sections to continue into the payload per
> > (1b) is potentially the most useful solution.
> >
> > It saves configuring the capture of seperate header and payload elements
> > where capture of the header and first few octets of the payload are
> > desired for packet identification and analysis.

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>