Embed Size (px)
Citation preview
1
PSAMP Protocol SpecificationsIPFIX IETF-64 November 10th, 2005
<draft-ietf-psamp-protocol-02.txt>
Benoit Claise <[email protected]>
Juergen Quittek <[email protected]>Andrew Johnson <[email protected]>
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
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 Selector … SelectedPackets
Selector IDSelector IDObs. Pt ID …
Associations ID
444
High Level View
Packet Report:
Packet Interpretation:
Template Record (associations Id, packet sample, selector sequence number)
Associations Report InterpretationOptions Template Record (Scope=associations Id, Observation Point, selector Id )
Selector Report InterpretationOptions Template Record (Scope=selector Id, selection method, selection parameters)
555
Data Record Example 1
Packet Report:
Packet Interpretation:
Associations Report InterpretationData Record (Scope=associationsId = 1, ingressInterface 1, selectorId X )
Selector Report InterpretationData Record (Scope=selectorId X, selectorAlgorithm=systematic count based sampling, samplingPacketInterval =1, samplingPacketSpace = 99 )
Data Record (associationsId 1, ipPayloadPacketSection …, selectorInputSequenceNumber …)
666
Data Record Example 22 Selector in the Associations
Packet Report:
Packet Interpretation:
Associations Report InterpretationData Record (Scope=associationsId, ingressInterface 1, selectorId X, selectorId Y)
Selector Report InterpretationData 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 InterpretationData Record (Scope=selectorId X, selectorAlgorithm=random n-out-of N sampling, samplingSize =1, samplingPopulation = 10 )
777
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.
888
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
999
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]
101010
Packet headers+ portion of
payloadPacket reports
Packet headers+ portion of
payload
Packet reports
Flow recordsPacket headers Flow records
Open Issue: TerminologyIPFIX and PSAMP Architecture
CollectingProcess
MeteringProcess
Obser-vationPoint
ExportingProcess
CollectingProcess
SelectionProcess
Obser-vationPoint
ExportingProcess
IPF
IXP
SA
MP
ReportingProcess
Measurement Process
111111
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 ?
121212
Open Issue #7IPFIX 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: <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
Observation Point
Packets Selector Selector … SelectedPackets
Selector IDSelector IDObs. Pt ID …
Associations ID
Metering Process
131313
Open Issue #8Selector 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…)
141414
Open Issue #11How 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 Selector … SelectedPackets
Selector IDSelector IDObs. Pt ID …
Associations ID
151515
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 <[email protected]>
Juergen Quittek <[email protected]>Andrew Johnson <[email protected]>
