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

From: "Carter Bullard" <[email-masked]>
Date: Mon, 11 Feb 2002 20:41:50 -0500

Excellent!  Sorry that I missed it when I went through
the first time!

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: Monday, February 11, 2002 11:32 AM
> To: [email-masked]
> Cc: 'Simon Leinen'; [email-masked]; 'data'
> Subject: [ipfix-data] Re: Information Model supporting vendor 
> specific IE's
> 
> 
> 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.
> 
> 
> 
> 
> Carter Bullard wrote:
> > 
> > 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/
> 
> 

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