1. 1 PSAMP Protocol Specifications IPFIX IETF-64 November 10th, 2005 Benoit Claise Juergen Quittek Andrew Johnson

2. 222 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. 333 Definitions 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]. Observation Point Packets Selector … Selected Packets Selector ID Obs. Pt ID … Associations ID

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

5. 555 Data Record Example 1 Packet Report: Packet Interpretation: Associations Report Interpretation Data 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 ) Data Record (associationsId 1, ipPayloadPacketSection …, selectorInputSequenceNumber …)

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

7. 777 Open Issue #3 Identical 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. 888 Open Issue #2 Field 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. 999 Open Issue #9 Field 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. 10 Packet headers + portion of payload Packet reports Packet headers + portion of payload Packet reports Flow recordsPacket headersFlow records Open Issue: Terminology IPFIX and PSAMP Architecture Collecting Process Metering Process Obser- vation Point Exporting Process Collecting Process Selection Process Obser- vation Point Exporting Process IPFIX PSAMP Reporting Process Measurement Process

11. 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. 12 Open Issue #7 IPFIX processes in the associations ID [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: " 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 Observation Point Packets Selector … Selected Packets Selector ID Obs. Pt ID … Associations ID Metering Process

13. 13 Open Issue #8 Selector Input Sequence Number [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 Packet Report: Data Record (associationsId 1, ipPayloadPacketSection …, selectorInputSequenceNumber for X…) selectorInputSequenceNumber for Y…)

14. 14 Open Issue #11 How to represent the Observation Point? 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 Observation Point Packets Selector … Selected Packets Selector ID Obs. Pt ID … Associations ID

15. 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. 16 PSAMP Protocol Specifications IPFIX IETF-64 November 10th, 2005 Benoit Claise Juergen Quittek Andrew Johnson