Subject: [ipfix-data] Information Model supporting vendor specific IE's

From: "Carter Bullard" <[email-masked]>
Date: Sat, 9 Feb 2002 10:42:05 -0500

Gentle People,
We'll need an of IE type that supports vendor specific
metrics. Rather than requiring that an IE be approved,
we should support vendor proprietary IE's in order to
transport unique metrics.  Ones that are not defined
in the RFC.  The inclusion of these IE types would
be advertised at connect time, and the collector can
decide if it will pass them through or not.

I didn't see this in the list.

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

[email-masked]
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

> -----Original Message-----
> From: majordomo listserver 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Wednesday, February 06, 2002 11:11 AM
> To: Simon Leinen
> Cc: [email-masked]; data
> Subject: [ipfix-data] Re: Information Model
> 
> 
> 
> 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/
> 
> 

--
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: [email-masked]
Date: Mon, 11 Feb 2002 11:31:59 -0500

Alrady there...

9.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.