Subject: Re: [ipfix-info] simple editorial changes for the information model draft

From: Juergen Quittek <[email-masked]>
Date: Wed, 06 Jul 2005 17:18:34 +0200

Hi Benoit,

--On 6/27/2005 9:28 PM +0200 Benoit Claise wrote:

> Hi Juergen,
>
> Sorry for the delay in replying to you.

It also took a long time until I had time to answer.

>> Benoit,
>>
>> This is just a reply to you.  The mailing list is not yet included.
>>
>> I am sorry for not posting the full list.  Accidentally, I omitted
>> ipTypeOfService, ipDscp, and ipPrecedence.  Wit a bit more elaborated
>> descriptions,
>> their proposed specification is
>>
>> 5.3.16  ipClassOfService
>>
>>   Description:
>>      For IPv4 packets, this is the value of the TOS field in the IPv4
>>      packet header.
>
> Full stop, new sentence.

Done.

>> for IPv6 packets, this is the value of the Traffic
>>      Class field in the IPv6 packet header.
>>   Abstract Data Type: octet
>>   Data Type Semantics: identifier
>>   ElementId: 194
>>   Status: current
>>   Reference: See RFC 791 for the definition of the IPv4 TOS field.  See
>>      RFC 2460 for the definition of the IPv6 Traffic Class field.
>
>>
>> 5.3.17  ipDiffServeCodePoint
>>
>>   Description:
>>      The value of a Differentiated Services Code Point (DSCP).  DSCP
>>      values are encoded in the first 6 bits of the IPv4 TOS field or
>
> The DSCP value is encoded in ...

Done.

>>      the IPv6 Traffic class field, respectively.
>>      For a particular Flow or packet, this Information Element may have
>>      the same value as Information Element ipClassOfService except that
>>      the bits that are not used by the Differentiated Services Field
>>      for specifying a DiffServ Code Point (DSCP) are to be ignored.
>
> I'm not too sure what you by the previous sentence. Which bits are to be
> ignored?
> I think your first sentence is enough from a specification point of view.
>
>>      Note that ignoring these bits may be relevant when the DSCP serves
>>      as Flow Key.
>
> We don't want to speak about flow key/flow value in the information model

The ONLY reason for defining this IE is for using it as flow key.
For all other cases, the value of ipClassOfService can be used and
ipDiffServeCodePoint is redundant.

>>   Abstract Data Type: octet
>>   Data Type Semantics: identifier
>>   ElementId: 195
>>   Status: current
>>   Reference: See RFC 791 for the definition of the IPv4 TOS field.  See
>>      RFC 2460 for the definition of the IPv6 Traffic Class field.  See
>>      RFC 2474 for the definition of the Differentiated Services Field.
>
>
>>
>> 5.3.18  ipPrecedence
>>
>>   Description:
>>      The value of the IP Precedence.  IP Precedence values are encoded
>>      in the first 3 bits of the IPv4 TOS field or the IPv6 Traffic
>>      class field, respectively.
>
> The IP Precedence value is ...

Done.

>>      For a particular Flow or packet, this Information Element may have
>>      the same value as Information Element ipClassOfService except that
>>      the last 5 bits are to be ignored.  Note that ignoring these bits
>>      may be relevant when the IP Precedence serves as Flow Key.
>
> Same remark as before. I think that the first sentence is enough.

The ONLY reason for defining this IE is for using it as flow key.
For all other cases, the value of ipClassOfService can be used and
ipPrecedence is redundant.

>>   Abstract Data Type: octet
>>   Data Type Semantics: identifier
>>   ElementId: 196
>>   Status: current
>>   Reference: See RFC 791 for the definition of the IPv4 TOS field and
>>      the IP Precedence.  See RFC 2460 for the definition of the IPv6
>>      Traffic Class field.
>>
>> 5.3.27  fragmentFlagsIPv4
>>
>>   Description:
>>      The value of the fragmentation bits in the IPv4 packet header.
>>
>>         Bit 0:    reserved, must be zero.
>>         Bit 1:    (DF) 0 = May Fragment,  1 = Don't Fragment.
>>         Bit 2:    (MF) 0 = Last Fragment, 1 = More Fragments.
>>         Bits 3-7: (DC) Don't Care, value is irrelevant.
>>
>>             0   1   2   3   4   5   6   7
>>           +---+---+---+---+---+---+---+---+
>>           |   | D | M | D | D | D | D | D |
>>           | 0 | F | F | C | C | C | C | C |
>>           +---+---+---+---+---+---+---+---+
>
> I don't see why we should speak about the 8 bits.
> I think we should say: "the value of the fragmentation bits of the IPv4
> header, as specified in "Flags" fields of RFC791.

The data type is octet.  We need to clearly specify where in the octet
the relevant bits are coded.

>>
>>   Abstract Data Type: octet
>>   Data Type Semantics: flags
>
> This should be an identifier.

What would be identified?
It is two flags:
one requesting not to fragment
and one indicating the last fragment.

>>   ElementId: 197
>>   Status: current
>>   Reference:
>>      See RFC 791 for the specification of the IPv4 fragment flags.
>>
>>
>> For the remaining Element you list I ran into open issues when specifying
>> them, particularly when reading the references to be included.
>> Please find comments inline below.
>>
>>
>> --On 6/20/2005 2:20 AM +0200 Benoit Claise wrote:
>>
>>> Hi Juergen,
>>>
>>> Thanks for posting the list of I.E.s
>>>
>>> You forgot some I.E.s that we discussed and agreed upon, as far as I
>>> remember.
>>>
>>> 1. mplsTopLabelEXP
>>>    Description: the top MPLS label experimental bits.
>>>    Abstract Data Type: octet
>>>    Data Type Semantics: flags
>>>    ElementId: x
>>>    Status: current
>>>    Reference 2.1 in RFC3032
>>
>>
>> 1. These flags are already included in object mplsLabelStackEntry1.
>> 2. I could not find references to any use of these experimental bits.
>>   RFC 3032 just says they are reserved.  Do we have an application
>>   scenario where these are used?
>
> Class of Service in MPLS network, to generate the core traffic matrix
> for capacity planning.
> You will find references in RFC3270

Added this IE.

>>
>>> 2.  IPPayloadLength
>>>     Description: Length of the IP payload in octets.
>>>     Abstract Data Type: unsigned16
>>>     Data Type Semantics: quantity
>>>     ElementId: x
>>>     Status: current
>>
>>
>> The definitions of payload are different for IPv4 and IPv6.
>>
>> For IPv4 there is no header field indicating the payload length,
>> we just have the 'total Length' header field.  The IPv4 actual payload
>> length is the difference between the 'Total Length' and the actual
>> header length.  The IPv4 header length is variable, because IPv4 optinons
>> are included in the header.
>>
>> For IPv6 there is a 'Payload Length' field in the header :-),
>> but the actual payload length may differ from the value of this field :-(
>> For Jumbograms the value of the 'Payload Length' header field is zero
>> and the actual value is specified in an extensions header.
>>
>> IPv4: actual payload length = packet length - base header length -
>> total options length
>> IPv6: actual payload length = packet length - base header length
>
> That's right! Feel free to insert to the description

I still do not know what is the right thing to use.

I suggest moving this to the PSAMP info model.
Anyway, with the recent additions of IE's there are not too many
packet properties left for PSAMP.

>>
>>> 3. mplsHeaderLength
>>>     Description: The sum of the MPLS label stack entries
>>>     Abstract Data Type: octet
>>>     Data Type Semantics: quanity
>>>     ElementId: x
>>>     Status: current
>>
>>
>> This is included.  RFCs 3031/3032 rather call it MPLS label stack
>> than MPLS header.  That's why I renamed it to mplsLabelStackSize.
>
> Fine.

Also added mplsLabelStackDepth on request from Stewart.

>>
>>> 4. mplsPayloadLength:     Description: the payload after last MPLS
>>> label stack entry.
>>>     Abstract Data Type: unsigned16
>>>     Data Type Semantics: quantity
>>>     ElementId: x
>>>     Status: current
>>
>>
>> This is the IP packet length.
>> It should be called accordingly.
>
> What if you don't have IP within MPLS?

Then it is not IP Flow Information eXport.

>>
>>> 5.  IPTos
>>>     Description: IP Type Of Service.
>>>     Abstract Data Type: octet
>>>     Data Type Semantics: identifier
>>>     ElementId:  x
>>>     Status: current
>>>
>>>     Note: this is the full 8-bit octet
>>>     Note:
>>
>>
>> I really missed this one.  Please see above.
>
> Covered above now with your proposal. Fine.

Added this IE.

>>
>>> 6. IPDSCP
>>>     Description: IP DSCP.
>>>     Abstract Data Type: octet
>>>     Data Type Semantics: identifier
>>>     ElementId: x
>>>     Status: current
>>>        Note: this is 6 bits of DSCP information
>>
>>
>> See above.
>
> Covered above now with your proposal. Fine.

Added this IE.

>>
>>> 7. IPPrecedence
>>>     Description: IP precedence.
>>>     Abstract Data Type: octet
>>>     Data Type Semantics: identifier
>>>     ElementId: x
>>>     Status: current
>>>     Reference: RFC 791
>>>     Note: this is the 3 bits of precedence information
>>
>>
>> See above.
>>
> Covered above now with your proposal. Fine.

Added this IE.

>>> 8. IPv4HeaderLength
>>>     Description: IPv4 header length .
>>>     Abstract Data Type: unsigned16
>>>     Data Type Semantics: quantity
>>>     ElementId: x
>>>     Status: current
>>
>>
>> We have the IP header length.
>
> We need the IPv4 header length in case we don't want to have another
> flow key (protocol)

Added this IE.

>>
>>> 9. IPv4Flags
>>>     Description: IPv4 fragmentation flags.
>>>     Abstract Data Type: 8bits
>>>     Data Type Semantics: flags
>>>     ElementId: x
>>>     Status: current
>>
>>
>> I really missed this one.  Please see above.
>
> Covered above now with your proposal. Fine.

Added this IE.

>>
>>> 10. IPv4Options
>>>     Description: Bitmap representing which IPv4 options have been seen.
>>>     Abstract Data Type: 32bits
>>>     Data Type Semantics: flags
>>>     ElementId: x
>>>     Status: current
>>>     Reference: "flags" from the IP header, RFC791
>>
>>
>> RFC 791 specifies 8 different options:
>>  1. End of Option list
>>  2. No Operation
>>  2. Security
>>  4. Loose Source Routing
>>  5. Strict Source Routing
>>  6. Record Route
>>  7. Stream ID
>>  8. Internet Timestamp
>>
>> Options 1 and 2 do not contain real information, they
>> just serve syntactical and alignment purposes.
>> Shall we include them also or limit the option list to the remaining
>> six options.
>
> I would simply copy everything from the Options in RFC791. Otherwise,
> there is a source of confusion.
>
>>
>> Are there more options defined anywhere outside of RFC 791?
>
> This is not relevant. Let's just copy everything.
>
>> Do we really need and unsigned32?  For these 6-8 options described
>> above an octet or unsigned 16 would already be sufficient.
>
> The Options value is 24 bits, so 32 bits make sense.
> We would have to specify that the top 8 bits are unspecified.

Added this IE.

The IP options are maintained by IANA. Currently, 24 are defined.
If we choose unsigned 32, we have 8 more options until we cannot support
any more. Therefore I used unsigned64.

>>
>>> 11. TCPOptions
>>>     Description: TCP options field
>>>     Abstract Data Type: 32bits
>>>     Data Type Semantics: flags
>>>     ElementId: x
>>>     Status: current
>>>     Reference: RFC 793
>>
>>
>> A single TCP packet may contain more than one option.
>
> That's right, for example from RFC793
>
>     Note that the list of options may be shorter than the data offset
>     field might imply.  The content of the header beyond the
>     End-of-Option option must be header padding (i.e., zero).
>
>
>> The list of allowed options is maintained by IANA at
>> <http://www.iana.org/assignments/tcp-parameters>.
>> The list already contains 26 entries and TCPM is currently
>> working on further options.  Therefore, unsigned32
>> does not appear to be appropriate, because it probaly will
>> become too small in the very near future.  We should at least
>> use an unsigned64 data type here.  we can use the IANA-assigned
>> option number as indicator for the position in the bit field
>> array for the respective TCP option.
>
> If you want unsigned64, fair enough.
> Anyway, this is the max value, so using a reduced length of 32 bits can
> be enough to start with.

Added this IE with type unsigned64.

>>
>>
>>>
>>>
>>> Finally, one comment regarding the two postMCastPacketTotalCount  and
>>> postMCastOctetTotalCount  I.E.
>>> - is it important to specify "created for packets of this Flow by an
>>> adjacent
>>>   multicast daemon"
>>
> what about this one?
>
>>> - regarding to "Note that typically not all of the created packets
>>> can be
>>>   observed at the Observation Point of this Flow.", I'm not sure it
>>> makes sense.
>>> What does "created" mean?
>>>    If you want to say that all IPFIX device wide multicast packets
>>> can't be observed,
>>>    I don't think this is relevant as the observation point is the
>>> interface.
>>>    This is even confusing.
>>
>>
>> I have no problem with replacing "created" by , for example, "sent".
>> Do you have another suggestion?
>
> Created is better but it doesn't clear the confusion: this is not
> relevant as the observation point is the interface.

I put 'sent' instead.

> Thanks Juergen.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

--
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: Juergen Quittek <[email-masked]>
Date: Wed, 06 Jul 2005 18:30:22 +0200

Benoit,

--On 6/11/2005 3:34 PM +0200 Juergen Quittek wrote:

>> - Section 5.  Information Elements
>>
>>    "The Information Elements that are derived from fields of packets or
>>    from packet treatment, such as the Information Elements in groups
>>    3.-6., can serve as Flow Keys used for mapping packets to flows.  But
>>    they also may contain values that are not constant for a single flow.
>>    For example a flow using a certain source IPv4 address as flow key
>>    has sourceIPv4Address as constant property but may have
>>    destinationIPv4Address as a property that changes from packet to
>>    packet."
>>
>> I don't understand the sentence starting with "But".
>> Either this is a flow key, and then this I.E. is constant in a flow.
>> Or it's not a flow key and it's not worth mentioning!
>> I mean... by definition a flow is defined by his flow keys.
>> So the following sentence is wrong
>> "But they (I understand by "they", the I.E.s that serve as Flow Keys"
>> also may contain values that are not constant for a single flow."
>
> This is a lost editorial edit.  I fixed this already, but here we have
> the old version.  I'll post the improved version to the list when I am
> back in the office and can retrieve it from the CVS server.

Here is the modified version of this text:

   The Information Elements that are derived from fields of packets or
   from packet treatment, such as the Information Elements in groups
   3.-6., can serve as Flow Keys used for mapping packets to Flows.

   If they do not serve as Flow Keys, their value may change from packet
   to packet within a single Flow.  For Information Elements with values
   that are derived from fields of packets or from packet treatment and
   for which the value may change from packet to packet within a single
   Flow, the IPFIX information model defines that their value is
   determined by the first packet observed for the corresponding Flow,
   unless the description of the Information Element explicitly
   specifies a different semantics.  This simple rule allows writing all
   Information Elements related to header fields once when the first
   packet of the Flow is observed.  For further observed packets of the
   same Flow, only Flow properties that depend on more than one packet,
   such as the Information Elements in groups 7.-9., need to be updated.

Thanks,

    Juergen