I understood the use of setting the length to zero was for unsupported attributes. If the intention is to use this for wildcards, then why is there a distinct wildcard value indicated for the protocol and DSCP attributes?
Kwok Ho Chan wrote:
Brian: Please see inline below. -- Kwok -- At 11:54 AM 11/8/02 +1100, Brian Williams wrote:Hi Kwok.
I still am not clear how you would indicate a value to match all FlowIDs, and hence the FlowId can be ignored. Please see further inline.
Kwok Ho Chan wrote:
Brian, Emmanuel: We do not need wildcard for the frwkIpFilterFlowId attribute in the Framework PIB's frwkIpFilterEntry. The reasoning is as follows:<snip>I assume you are using this as the key point. What I am after is how you tell the node that it is not doing flow-specific treatment, and therefore the field can be ignored. That is, what do you send in the PIB to tell the node that the FlowId is not used? This is not case 1, 2, or 3 below.If an IPv6 node is not providing flow-specific treatment, it MUST ignore the field when receiving or forwarding a packet.
The encoding of the frwkIpFilterFlowId attribute can have a length of zero, used to
indicate the attribute is not used (please see COPS-PR RFC 3084).
is used to indicate this attribute is not used as part of the filter definition and will
not contribute to the filtering action, resulting in a "don't care" condition for
frwkIpFilterFlowId, the meaning of a wildcard match for this attribute.
the draft-ietf-ipv6-flow-label-03.txt draft indicate that there can be 3 conditions
for the Flow Label field of the IPv6 header:
1. It contain the value of zero, meaning it is not used.
2. It contain some specific value, with no defined syntax and semantics.
Hence each value is unique on its own with no relationship to Flow Labels
of containing another value.
3. It contain some value other than zero.
For the first 2 cases indicated above, the filter setup for them is trivial, just
set the frwkIpFilterFlowId to zero or the specific value needed.
This is clear.For the 3rd case, the filtering definition should use the frwkBaseFilterNegation
set to true and frwkIpFilterFlowId set to zero. This will indicate a filter match
for all Flow Label values other than zero.
This is also clear.Please let me know if this does not resolve the question you have. Thanks! -- Kwok -- At 09:13 AM 11/8/02 +1100, Brian Williams wrote:Hi Emmanuel. Please see comments inline. /brian Emmanuel Dumont wrote:I consider that a wildcard would be needed for FlowId as much as for the other attributes (eg DSCP). I think there would need to be an explanation of why one is not provided.Hi Brian, Do you think a wildcard is needed for the FlowId attribute ?
Which one could you suggest ?I would think a value of -1 (as used for DSCP) would be appropriate.Kwok: is it an omission in the FR-PIB ? Maybe an IPv6 expert can help us to solve that question... Brian : Do you think that others wildcards are missing ?
This is the only one that I have identified is missing from the filter. I have not done a careful check on anything else in the document.
Emmanuel Dumont ---------------------------- France Telecom OCISI/DIeP (Guyancourt, France) Mail: email@example.com / firstname.lastname@example.org ---------------------------- -----Message d'origine----- De : email@example.com [mailto:firstname.lastname@example.org]De la part de Brian Williams Envoye : mercredi 6 novembre 2002 00:46 A : email@example.com Objet : wildcard flowid in framework PIB? Hi All. I have a question on the framework PIB. When I look at many of the filter attributes, there exist values that can be used as wildcards. The following are a few examples: - for source and destination addresses, a prefix length of 0 indicates a match of any address - for DSCP, a value of -1 will match all DSCP values - for port numbers, you can set the min and max to include all values - for protocol number, a value of 255 means match all However, for the FlowId, the range is specified as 0..1048575 which is the valid range of the 20 bit label. How is a wildcard FlowId indicated? /brian