Jerry,> >For example, in Section 2 "Conclusions & Recommendations", the > >very first requirement is: > > > >'(1) Requirements for specific TE measurements > > > >. Node-pair-based traffic data to derive per-service-class > >traffic matrix statistics, including statistics of carried > >load and offered load (Sections 3.3 and Appendix A) > >. Statistics of achieved performance and throughput (Section 3.4) > >. A standardized method to detect and record label binding > >changes for LDP-signaled label-switched paths, at the > >ingress-egress pair level (Section 3.5)' > > > >Such a requirement is basic to operating any network, and > >allows a traffic matrix to be derived for purposes of > >engineering and management of the network. Such a measurement > >*is not available in any MIB or protocol*. It is a major > >problem in the engineering and management of IP-based networks > >today that such measurements are not available. There are > >indirect work-arounds to this that are not altogether accurate > >or satisfactory, but there is no substitute for the actual > >measurements. > That is not entirely accurate. The IETF's IPFX WG is > standardizing the NetFlow protocol which can be used for > precisely this. It has been available in a proprietary form > from my company and others for several years now. I believe it is accurate. We are, of course, familiar with IPFX/NetFlow, and have used NetFlow for many years in AT&T. NetFlow has its place, but does *not* satisfy the requirement for node-node measurements as called for in the I-D. I see from the draft that you have multiple requirements. Some of them could be fulfilled with IPFIX Traffic measurement can be performed on the basis of flows, interfaces, links, nodes, node-pairs, or paths. Based on these objects, different measurement entities can be defined, such as traffic volume, average holding time, bandwidth availability, throughput, delay, delay variation, packet loss, and resource usage. Using these measured traffic data, in conjunction with other network data such as topological data and router configuration data, traffic matrix and other relevant statistics can be derived for TE purposes. If you would report flow records composed of BGP Next Hop and TOS or flow records composed of FEC (IP address) and EXP, you would have a pretty good idea of your core traffic matrix. You wrote also regarding the flow-based measurements: Some shortcomings in today's method to derive traffic matrix statistics as above include the volume of data from flow-based measurement, the lack of sufficient routing control information, and the need to correlate data from a variety of sources. Volume: Well, the volume of data will be as voluminious as you want it to be. Look at PSAMP for packet sampling. Note that PSAMP will use IPFIX as export protocol (and NetFlow version 9 was selected as the basis protocol for IPFIX). I think that packet sampling is fine anyway: we don't need a 100% precise core traffic matrix. Correlation: With the mechanism, you don't need to correlate anymore with the SNMP counters. Routing Control information: Could be an issue. IPFIX requires (http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-11.txt): The exporting process MUST be able to report the following attributes for each metered flow: 11. if MPLS is supported at the observation point: the top MPLS label or the corresponding forwarding equivalence class (FEC, [RFC3031]) bound to that label. The FEC is typically defined by an IP prefix. As you summarized in the table of section 4.1, the flow-based passive measurements can not answer all your requirement (example offered load). So I'm not telling that IPFIX/PSAMP is THE solution for all your problems. I'm just telling the core traffic matrix could be produced with IPFIX. And I'm just wondering if a possible extension to the IPFIX information model would help you exporting what you need, and help answering the requirement "Standardization of an information model for TE measurement."! To come back on the offered load, IMHO, it should be done off the network (not with active probing) with a tool that would take as input: the core traffic matrix, the topology and the routing tables info! Note: I'm also a little bit confused by Some shortcomings in today's method to derive traffic matrix statistics as above include the volume of data from flow-based measurement, the lack of sufficient routing control information, and the need to correlate data from a variety of sources. To avoid some of these deficiencies and to take advantage of the routing control offered by MPLS, node-pair-based passive measurement should be developed. And you defined in the appendix: A.3 Node-pair-based Active measurements by probing, as specified ... Regards, Benoit. |