[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Open issue 15: chunk with a too short length

Thomas Dietz wrote:

Dear Benoit, all,
Why don't we make the chunk elements by default variable length and just don't allow them to be fixed length?? 

I think in many cases the chunks will be sufficiently small to mean that
they are guaranteed to be complete.  i.e. a ipv4HeaderSection of 20 bytes.
Forcing a variable length field in this case will give more overhead than
necessary.

I think most sensible implementations will use a variable length for large
chunks in IPFIX, but specifying how to do it using templates gives a clear
direction to anyone implementing a dual IPFIX / NetFlow v9 exporter.


Andrew



--
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 90511-28
NEC Europe Ltd.                    Fax:    +49 6221 90511-55
Kurfuersten-Anlage 36
69115 Heidelberg, Germany http://www.netlab.nec.de <http://www.netlab.nec.de/> 
    ------------------------------------------------------------------------
    *From:* owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org]
    *On Behalf Of *Benoit Claise
    *Sent:* Wednesday, December 21, 2005 11:55 PM
    *To:* Benoit Claise
    *Cc:* psamp
    *Subject:* Re: Open issue 15: chunk with a too short length

    BTW, regarding [PSAMP-INFO], the 2 ipHeaderPacketSection and
    ipPayloadPacketSection information element descriptions currently
    contain:

        "If insufficient octets are available,
        the remainder of the data should be zero-filled and an additional
        information element sent (e.g., ipPayloadLength) indicating how
        much of the data is valid."

    Obviously these sentences will have to be removed.

    Regards, Benoit.


    Dear all,

    >From the Vancouver meeting minutes:

        Open Issue (not numbered): Chunk with too short length
        How to encode "chunk" with a too short length? Padding
        wouldn't be recognized
        by the collector. One solution would be using a new template
        for each length.
        Proposal: The protocol draft should say that padding MUST NOT
        be used for
        variable length IEs.

Here is a new proposed text (actually, only the second paragraph is new)

    Basic Packet Report

    For each selected packet, the Packet Report MUST contain the
    following information:
    - The associationsId Information Element
    - Some number of contiguous bytes from the start of the packet,
    including the packet header (which includes link layer, network
    layer and other encapsulation headers) and some subsequent bytes
    of the packet payload.  Alternatively, the number of contiguous
    bytes may start at the beginning of the payload. The
    Layer2PacketSection, l2PayloadPacketSection,
    mplsLabelStackSection, mplsPayloadPacketSection, ipPacketSection,
    and ipPayloadPacketSection PSAMP Information Elements are
available for this use. - The input sequence number(s) of any Selectors that acted on the 
    packet, represented by the selectorInputSequenceNumber Information
    Element.
The contiguous Information Elements (Layer2PacketSection, 
    l2PayloadPacketSection, mplsLabelStackSection,
    mplsPayloadPacketSection, ipPacketSection, and
    ipPayloadPacketSection) MAY be encoded with a fixed length field
    or with a variable sized field. If one of these Information
    Elements is encoded with a fixed length field whose length is too
    long for the number of contiguous bytes in the selected packet,
    padding MUST NOT be used. In this case, the Exporting Process MUST
    export the information either in a new Template Record with the
    correct fixed length field, or either in a new Template Record
with a variable length field. 

    Feedback?

    Regards, Benoit.





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