Subject: [ipfix-data] Re: Information Model

From: [email-masked]
Date: Wed, 06 Feb 2002 11:10:38 -0500

Here is a first cut at the list of data elements to be reported.
I of course hacked it out of the LFAP spec. 

I think we need to begin with a couple of guidlines (which
we should augment as we go). They are just guidelines.

        1. Data element values should be defined in terms of
           other specifications. Since we are only reporting
           things in other protocols, there should be little
           reason for us to define anything from scatch.

        2. Each element should be able to be interpreted on
           it own. In other words, don't make me look though    
           the rest of the message to figure out what this
           value means. The drawback is this can lead to
           data element explosion. We'll have to balance
           the tradeoffs.

        3. Others?....

1.1   Source Address IE

    Source address associated with a flow. Addresses can be of any type
    as described in RFC 1700 [note - we need a new reference here, 1700
    has been obsoleted]

1.2   Destination Address IE
   
   Destination address associated with a flow. same as above.

1.3   Internal queue priority
  
  A switch may map several of its internal priority queues into a
  Premium, High, Medium or Low category.

  [ this sections needs more work]

1.4   Time IE

  The time (as a SNMPv2 TimeStamp [1443]) associated with the
  status/statistics observed or other events.

1.5   UTC Time IE

  The time in seconds since 00:00:00 UTC, January 1, 1970 associated
  with the status/statistics observed or other events. If both Time
  and UTC_TIME are present, UTC Time takes precedence. 

1.6   Delta Time IE

  The number in 100ths of seconds over which the statistics were
  observed. TYPE is 71 and format is:

1.7   Class of Service IE

   The class of service associated with a flow. 

    Class of Service Received
    Class of Service Transmitted
 
      1 - IPv4, CoS value is defined by ToS in RFC 791
      2 - IPv6, CoS value is defined by Traffic Class in RFC 2460
      3 - MPLS, CoS value is defined by Exp in RFC 3032
      4 - VLAN, CoS value is defined by user_priority in IEEE
          802.1q[802.1q] and IEEE 802.1p[802.1p]
   
   [Can more than one Class of Service can be present??? PAC]

1.8   Source Exporter [ is that the right term?? PAC] Address IE

   Source Exporter address is the address of the Exporter reporting the
flow,
   Address is same as is as shown for Source Address. This
   information is used by applications to later correlate the
   ingress/egress port with a specific Exporter. It is also used to
   maintain the source Exporter information when there is an
intermediate
   proxy. For example, given the picture below:
   
            SW1 --------    P1 ------ FAS1
                            ^
                            |
            SW2----------   |
   
   Flows coming from SW1 and SW2 through proxy P1 would look to the
   Collector [ is this the rigth term??? PAC]  like the same Exporter 
   connection. With the Source Exporter in the message the original
Exporter 
   address is maintained.

1.9  Flow State IE

   Flow State is the intended End State for the Flow.
      
   Flow state has one of the following meanings:

         Flow is inactive
         Flow is active

1.10  Byte Count IE

   Contains the count of octets sent and received associated with the
   identified flow. 

  The byte count can be for bytes received (towards source) or 
        bytes sent (towards destination) or both (bi-directional flow).

  The byte count can be a running counter and is the
           count from the beginning of the flow establishment.
  The byte count can be a delta counter and is the
           count since the last report for this flow.

1.11  Packet Count IE

   Contains the count of packets sent and received associated with the
   identified flow. 

  The packet count can be for packets received (towards source) or 
        packets sent (towards destination) or both (bi-directional
flow).

  The packet count can be a running counter and is the
           count from the beginning of the flow establishment.
  The packet count can be a delta counter and is the
           count since the last report for this flow.

1.12  Protocol Identifier IE

        e.g. TCP/UDP [ need an RFC reference here. PAC] 

1.13  Source Port IE

   This IE is used to report  UDP source port [see RFC 768] or
   TCP source port [see RFC 793].

1.14  Destination Port IE

   This IE is used to report  UDP destination port [see RFC 768] or
   TCP destination port [see RFC 793].

1.15  Source AS IE

   The Autonomous System (AS) numbers for the source address
   associated with a flow. Autonomous System (AS) number is defined by
   RFC 1930 and RFC 1771 (BGP-4):

1.16  Destination AS IE

   The Autonomous System (AS) numbers for the destination address
   associated wit a flow. Autonomous System (AS) number is defined by
   RFC 1930 and RFC 1771 (BGP-4).

1.17  Ingress Port IE

   The ingress ifIndex for the flow is provided in this IE. ifIndex is
   defined by RFC 2233.

1.18  Egress Port IE

   The egress ifIndex for the flow is provided in this IE. ifIndex is
   defined by RFC 2233.

1.19  Egress ATM Subinterface

   The egress vpi/vci for the flow is provided in this IE. vpi/vci id
   defined by the ATM Forum UNI 3.1 specification:

1.20  EGRESS_FRAME_RELAY_SUBINTERFACE IE

  The egress DLCI for the flow is provided in this IE. ITU Q.922
  defines the DLCI range. The frDlcmiState is defined in RFC 2115 and
  defines the specific values of the DLCI.

1.21  NEXT_HOP_IP IE

   Address of the next hop. address is defined the same as for Source
   Address IE.

1.22  TCP Control Bits IE

   The TCP control bits seen for this flow. Note a 0 value for each
   bit only indicates that the flag was not detected (i.e. it may have
   occurred but was not detected by the reporting CCE). TCP Control
   Bits are defined by RFC 793. 

1.23  Next Hop AS IE

   The Autonomous System (AS) numbers for the next hop IP. Autonomous
   System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4).

1.24  Source Address Netmask IE

   The number of bits in the CIDR netmask, as defined in RFC 1519, for
   the source address.

1.25  Destination Address Netmask IE

   The CIDR netmask, as defined in RFC 1519, for the destination
   address. 

1.26  Destination BGP Community IE
  
  The BGP community number for the destination address. BGP community
  number is defined by RFC 1997:

1.27  Source BGP Community IE
  
  The BGP community number for the source address. 

1.28  Source VLAN ID IE
  
  The Source VLAN ID associated with the flow. VLAN ID is defined by
IEEE
  standard 802.1q - 1998[802.1q]. 

  [ Is this ultimate source VLAN or the source vlan of the port where
    the packet came in? Or do we need a way to represent both? PAC]

1.29  Destination VLAN ID IE
  
  The destination VLAN ID associated with the flow. VLAN ID is defined
by IEEE
  standard 802.1q - 1998[802.1q].
 
  [ Is this ultimate destination VLAN or the destination vlan of the
port where
    the packet went out? Or do we need a way to represent both? PAC]

1.30  Source Virtual Address IE

   An Exporter may be involved in redirecting flows. This IE captures
   information needed for proper accounting of redirected flows. The
   Source Virtual IE contains the source address of the flow as
   transmitted by the Exporter. It is generally different than the
source
   address IE, which contains the address of the actual source of the
   message. 
   
   A type field would contain the type of translation performed on the
   source address. The following types are currently available:
   
      1 - NAT
      2 - LSNAT
      3 - Web Cache

   The address is defined the same as for Source Address.

1.31  Source Virtual Port IE

   A CCE may be involved in redirecting flows. This IE captures
   information needed for proper accounting of redirected flows. The
   Source Virtual port IE contains the source port of the flow as
   transmitted by the CCE. It may be different than the source port
   IE, which contains the port of the actual source of the flow. 
   An IP Protocol field is present and is defined by the IP protocol 
   spec [RFC 791] (e.g. TCP/UDP). The fields indicates how to interpret 
   the port value field.

   A type field contains the type of translation performed on the
   source port. The following types are currently available:

      1 - NAT
      2 - LSNAT
      3 - Web Cache

1.32  Destination Virtual Address IE

   The Destination Virtual IE contains the destination address of the
   flow as received by the Exporter. It is generally different than the
   destination port number, which contains the actual destination
   address of the flow.

1.33  Destination Virtual Port IE

   The Destination Virtual port IE contains the destination port of
   the flow as received by the Exporter. It may be different than the
   destination port recorded in the destination port, which contains the
   actual destination port of the flow. 

1.34  Vendor Specific IE
  
  Vendors may add their own information to the protocol. Information
  contained in this IE is vendor specific. OID and OID Value is
  defined by ITU X.680.X683 (1997) and is encoded as defined by ITU
  X.690.691(1997). This IE MUST not contain any information which
  cannot be safely ignored by the Exporter or Collector. If multiple
Vendor
  Specific IE's with the same OID occur, then the vendor defines
  semantics of ordering.

1.35  Flow Label IE

   The Flow Label IE contains the IPV6 Flow Label information as
   defined by RFC 2460. 

1.36  Fragment ID IE

   The fragment ID associated with the flow. RFC 791 and RFC 2460
   define fragment ID.

--
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: Jc Martin <[email-masked]>
Date: Wed, 06 Feb 2002 14:25:15 -0800

See my comments inline.

>            reason for us to define anything from scatch.
There are two parts in the above. One is where the protocol field
is defined, and the other is where the field is encoded in another
standard.
So, for example, the source port is defined in  RFC 768, but it's
definition (representation ?) could be imported from RFC 1155 or CIM
(like RFC3060 is doing).

Also, it is worth mentioning the RFC 2924 as a source of information
elements.
At this point, I would like to say that there is already a great 
disparity between the various accounting mechanisms in the way
the information is represented, it would be nice if IPFIX is not
adding yet another way of counting packets (Acct-Output-Octets,
Forward Packets,...)

>            data element explosion. We'll have to balance

Is that preventing the use of template ?

>         3. Others?....

Should add something about the naming of attributes, using OIDs, DNs, ...

Also, I would like to see some positioning with regards to CIM and SMIv2.
Even if the attributes are defined in a template, both the template and 
the attributes should be named through a standard naming scheme.

[snip]
>    [Can more than one Class of Service can be present??? PAC]

Is there any interest in counting the number of packets/bits with the 
ECN (RFC 3168), or do you see that as an extension ?

[snip]

>            count since the last report for this flow.

What do you mean by "can be" in the above cases ? It's either one or the
other, and this need to be specified, or allowed in the coding.

[snip]

>   Vendors may add their own information to the protocol. Information

what does this sentence means ? Which protocol ?

>   Specific IE's with the same OID occur, then the vendor defines

you are mentionning the OID here, what about the other elements ?

[snip]

JC

---

From: Jc Martin <[email-masked]>
Date: Wed, 06 Feb 2002 14:43:03 -0800

I reply to myself ,...

> adding yet another way of counting packets (Acct-Output-Octets,
The "counting packets" is just an example, and all elements are subject
to the same remark.

JC.

---

From: [email-masked]
Date: Fri, 08 Feb 2002 11:19:36 -0500

> definition (representation ?) could be imported from RFC 1155 or CIM

	Are you talking about format on the wire? If so, I'm
	not attempting to define that. Just semantics

> Is that preventing the use of template ?

	I don't think so. But if you define one field to be
	the port number and another to be the protocol
	then I need to look at 2 fields to determine if
	it is a UDP port or a TCP port. The field would be better
	defined as tcp-port and udp-port so the fields stand
	on their own.

> ECN (RFC 3168), or do you see that as an extension ?

	I have no problem with that if people think they
	would have a use for that info.

> other, and this need to be specified, or allowed in the coding.

	Right. can be just means there is more than one
	possible meaning. The encoding would have to 
	tell you which one it is.

> what does this sentence means ? Which protocol ?

	The IPFIX protocol. If we define the fields transported
	and vendor A wants to add their own home grown piece
	of data this is where they do it. 

> you are mentionning the OID here, what about the other elements ?

	I'm not sure how the other elements are encoded. But in this
	case we MUST provide a way for vendors to add stuff with out
	stepping on each other. This OID is one way to solve it. If
	we use OID for the other elements as well then we wont need
	special mention here. But until the encoding stuff is done
	I added mention of OID here.

---

From: Jc Martin <[email-masked]>
Date: Fri, 08 Feb 2002 09:19:45 -0800

>         not attempting to define that. Just semantics

Not only. You have some concepts, like Gauge, Counter, that have a specific 
semantic, and a well defined behavior.
I don't have other examples, but I suspect that all parameters that are not
directly derived from a protocol would fold in the same group (like interfaces,...).

[snip]

>         I added mention of OID here.
I don't think that the notion of naming is specific to the encoding.
It's a basic feature of the information model. I think that this
should be spelled out in a specific section, and applied to all
attributes or standard templates.

JC.

---

From: [email-masked]
Date: Mon, 11 Feb 2002 10:13:22 -0500

> directly derived from a protocol would fold in the same group (like interfaces,...).

	Ahhh, so if I understand, you are saying that for things
	not coming from another protocol spec, there are likely
	definitions we can use from other specs. I recall seeing
	the Gauge, Counter stuff somewhere.

> attributes or standard templates.

	What I meant was that most of the accounting specs
	today create their own numbering system. If IPFIX
	does that then we need to use OID for the Vendor stuff.
	But if IPFIX has OIDs to refer (name) to their data elelemts
	then the vendor one will not be special.