Benoit Claise <bclaise@cisco> Juergen Quittek <quittek@cisco>

1. PSAMP Protocol SpecificationsIPFIX IETF-64 November 10th, 2005<draft-ietf-psamp-protocol-02.txt> Benoit Claise <bclaise@cisco.com> Juergen Quittek <quittek@cisco.com> Andrew Johnson <andrjohn@cisco.com>

2. Status • Previous draft 01 expired in August 2004, waiting for the IPFIX protocol • Requirements from: • draft-ietf-psamp-framework-10.txt (I-RFC) • draft-ietf-psamp-sample-tech-07.txt (Standard Track) • Using: • draft-ietf-ipfix-protocol-19.txt

3. Definitions SelectedPackets Observation Point … • Selector ID • The Selector ID is the unique ID identifying a Primitive Selector. • Associations ID • From all the packets observed at an Observation Point, only a few packets are selected by one or more Selectors. The Associations ID is a unique value describing the Observation Point and the Selector IDs through which the packets are selected. The Associations ID is represented by the associationsID Information Element [PSAMP-INFO]. Packets Selector Selector Selector ID Selector ID Obs. Pt ID … Associations ID

4. Packet Report: Packet Interpretation: High Level View Template Record (associations Id, packet sample, selector sequence number) Associations Report InterpretationOptions Template Record (Scope=associations Id, Observation Point, selector Id ) Selector Report Interpretation Options Template Record (Scope=selector Id, selection method, selection parameters)

5. Packet Report: Data Record Example 1 Data Record (associationsId 1, ipPayloadPacketSection …, selectorInputSequenceNumber…) Packet Interpretation: Associations Report InterpretationData Record (Scope=associationsId = 1, ingressInterface 1, selectorId X ) Selector Report Interpretation Data Record (Scope=selectorId X, selectorAlgorithm=systematic count based sampling, samplingPacketInterval =1, samplingPacketSpace = 99 )

6. Data Record Example 22 Selector in the Associations Packet Report: Data Record (associationsId 1, ipPayloadPacketSection …, selectorInputSequenceNumber for X…) selectorInputSequenceNumber for Y…) Packet Interpretation: Associations Report InterpretationData Record (Scope=associationsId, ingressInterface 1, selectorId X, selectorId Y) Selector Report Interpretation Data Record (Scope=selectorId X, selectorAlgorithm=random n-out-of N sampling, samplingSize =1, samplingPopulation = 10 ) Selector Report Interpretation Data Record (Scope=selectorId Y, selectorAlgorithm=systematic count based sampling, samplingPacketInterval =1, samplingPacketSpace = 99 )

7. Open Issue #3Identical Information Elements in a Data Record • Multiple identical Information Element are possible in PSAMP: selectorId, selectorInputSequenceNumber, hash value • [IPFIX-PROTO] doesn’t specify anything about multiple identical Information Elements? • [IPFIX-PROTO] expresses something about the scope: “if the order of the scope fields in the Option Template Record is relevant, the order of the scope fields MUST be used” • PROPOSAL: • Clarify [IPFIX-PROTO] • When a data record contain multiple identical Information Elements, the order of the Information Elements is important. The collector should store all of them.

8. Open Issue #2Field Match and Router State Filtering • From the protocol point of view, there are no differences between the Field Match and Router State Filtering • Some differences from a conceptual point of view • PROPOSAL: • Merge the 2 selection methods in [PSAMP-PROTO] and [PSAM-TECH], potentially with a new generic name such as “Property Match Filtering” • As a consequence in [PSAMP-INFO] selectorAlgorithm as well • [PSAMP-TECH] explains the two sorts of match: Field Match and Router State

9. Open Issue #9Field Match and Router State Filtering I.E. • Deduced from [PSAMP-TECH], [PSAMP-PROTO] says: • "The algorithm specific Information Elements, defining configuration parameters for match-based and router state filtering, are taken from the full range of available IPFIX Information Elements [IPFIX-INFO]". • What about the ones from [PSAMP-INFO]? What about the future ones from IANA, not included in [IPFIX-INFO] • Example: [PSAMP-TECH] mentions filtering based on access-list, reverse path forwarding • PROPOSAL: • Remove this restriction in both the [PSAMP-TECH] and [PSAMP-PROTO]

10. Open Issue: TerminologyIPFIX and PSAMP Architecture Packet headers Flow records Flow records Obser- vation Point Metering Process Exporting Process Collecting Process IPFIX Measurement Process Obser- vation Point Selection Process Reporting Process Exporting Process Collecting Process PSAMP Packet headers + portion of payload Packet headers + portion of payload Packet reports Packet reports

11. Open Issue: Terminology • PROPOSAL: • Renaming the PSAMP measurement process to metering process • Dropping the concepts of selection process and reporting process ? • just keep the metering process ?

12. Open Issue #7IPFIX processes in the associations ID SelectedPackets Observation Point … Packets Selector Selector • [PSAMP-TECH] section 7.1 and 7.2 describes that: • "The ASSOCIATIONS field describes the Observation Point and optionally the IPFIX processes to which the packet Selector is associated. Values: <STREAM ID, IPFIX Metering process ID, IPFIX Exporting process ID, IDs of other associated processes>" • Can’t think of a case where the IPFIX metering process IDs would be useful. Does someone have a case in mind? • PROPOSAL: • Don’t mention the IPFIX processes in order to avoid confusion Selector ID Selector ID Obs. Pt ID … Associations ID Metering Process

13. Open Issue #8Selector Input Sequence Number Packet Report: Data Record (associationsId 1, ipPayloadPacketSection …, selectorInputSequenceNumber for X…) selectorInputSequenceNumber for Y…) • [PSAMP-PROTO] "the Packet Report MUST contain the input sequence number(s) of any Selectors that acted on the packet • Issue: counter64 for each selector sent part of every data record • Do we want to mandate this? • PROPOSAL: • MUST be able to send selector input sequence number in packet report • MAY use the mechanism • MAY send the selector input sequence number in a packet interpretation (option template record) on regular basis

14. Open Issue #11How to represent the Observation Point? SelectedPackets Observation Point … Packets Selector Selector • Should we have an Observation Point ID I.E.? • PROS: Very flexible • CONS: We should specify the management of it! • CONS: We should export the relationship with know I.E.. Example: this observation point X is composed of ingressInterface Y • Or can reuse any I.E.: interface, line card, router? • PROS: Very easy • PROS: Could even define new ones, depending on specific architecture • NOTE: the observation point I.E. MUST always be the first one in the Association ID report interpretation, and must be interpreted that way by the collector! • PROPOSAL: • “Reuse any I.E.” method Selector ID Selector ID Obs. Pt ID … Associations ID

15. Open Issue How to encode “chunk” with a too short length? • What if we configure the ipPayloadPacketSection for 50 bytes and we get a 30 bytes ipPayloadPacketSection ? • Padding? The collector will not know that there are some padding octets! • PROPOSAL: • MUST not send any padding information • MAY send the “short” chunk with a variable length I.E. (this implies a new template if the chunk was sent as a fixed size I.E) • MAY send the “short” chunk with a fix size

16. PSAMP Protocol SpecificationsIPFIX IETF-64 November 10th, 2005<draft-ietf-psamp-protocol-02.txt> Benoit Claise <bclaise@cisco.com> Juergen Quittek <quittek@cisco.com> Andrew Johnson <andrjohn@cisco.com>