John,
I'll come back with this when IPv6 WG consensus exists. I think we're pretty
close now.
Is there a hard deadline for any new issues for Diameter?
Jarno
[EMAIL PROTECTED] wrote:
>
> Yes, it would be inappropriate. The meaning of flow labels was clearly
> not defined in Minneapolis (IETF 50). The draft minutes from London
> http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-a
> ug2001.txt
> indicated some controversy remains, with a call for
> "Further discussion on mailing list."
>
> John
>
> At 09:04 AM 9/4/2001, [EMAIL PROTECTED] wrote:
> >Pat,
> >
> >Would it be inappropriate at this time to ask the QoSFilterRule to be
> >extended to include an optional IPv6 flow label value (20 bits) to be
> >matched by the filter?
> >
> > Jarno
> >
> >> -----Original Message-----
> >> From: ext Pat Calhoun [mailto:[EMAIL PROTECTED]]
> >>...
> >> QoSFilterRule
> >> The QosFilterRule format is derived from the
> OctetString AVP
> >> Base Format. It uses the UTF-8 encoding and has the same
> >> requirements as the UTF8String. Packets may be marked or
> >> metered based on the following information that
> is associated
> >> with it:
> >>
> >> Direction (in or out)
> >> Source and destination IP address (possibly masked)
> >> Protocol
> >> Source and destination port (lists or ranges)
> >> DSCP values (no mask or range)
> >>
> >> Rules for the appropriate direction are evaluated
> in order,
> >> with the first matched rule terminating the
> evaluation. Each
> >> packet is evaluated once. If no rule matches, the
> packet is
> >> treated as best effort.
> >>
> >> QoSFilterRule filters MUST follow the format:
> >>
> >> action dir proto from src to dst [options]
> >>
> >> tag - Mark packet with a specific
> >> DSCP [49].
> >> The DSCP option MUST be included.
> >> meter - Meter traffic. The
> metering options
> >> MUST be included.
> >>
> >> dir "in" is from the terminal, "out" is to the
> >> terminal.
> >>
> >> proto An IP protocol specified by
> number. The "ip"
> >> keyword means any protocol will match.
> >>
> >> src and dst <address/mask> [ports]
> >>
> >> The <address/mask> may be specified as:
> >> ipno An IPv4 or IPv6 number
> in dotted-
> >> quad or canonical IPv6
> form. Only
> >> this exact IP number
> will match
> >> the rule.
> >> ipno/bits An IP number as above
> with a mask
> >> width of the form
> 1.2.3.4/24. In
> >> this case all IP numbers from
> >> 1.2.3.0 to 1.2.3.255
> will match.
> >> The bit width MUST be
> valid for the
> >> IP version and the IP
> number MUST
> >> NOT have bits set
> beyond the mask.
> >>
> >> The sense of the match can be inverted by
> >> preceding an address with the not
> modifier,
> >> causing all other addresses to be matched
> >> instead. This does not affect
> the selection
> >> of port numbers.
> >>
> >> The keyword "any" is 0.0.0.0/0
> or the IPv6
> >> equivalent. The keyword
> "assigned" is the
> >> address or set of addresses assigned
> >>
> >> to the terminal. The first
> rule SHOULD
> >>
> >> be "deny in ip !assigned".
> >>
> >> With the TCP, UDP and SCTP protocols,
> >>
> >> optional ports may be specified as:
> >>
> >> {port|port-port}[,port[,...]]
> >>
> >> The `-' notation specifies a
> range of ports
> >> (including boundaries).
> >>
> >> options:
> >>
> >> DSCP <color>
> >> color values as defined in [49].
> Exact matching
> >> of DSCP values is required (no
> masks or ranges).
> >> the "deny" can replace the color_under or
> >> color_over values in the meter
> action for rate-
> >> dependent packet drop.
> >>
> >> metering <rate> <color_under> <color_over>
> >> The metering option provides
> Assured Forwarding,
> >> as defined in [50], and MUST be
> present if the
> >> action is set to meter. The rate
> option is the
> >> throughput, in bits per second,
> which is used
> >> by the access device to mark
> packets. Traffic
> >> above the rate is marked with the
> color_over
> >> codepoint,
> >> while traffic under the rate is
> marked with the
> >> color_under codepoint. The color_under and
> >> color_over options contain the drop
> preferences,
> >> and MUST conform to the recommended
> codepoint
> >> keywords described in [50] (e.g. AF13).
> >>
> >> The metering option also supports the strict
> >> limit on traffic required by Expedited
> >> Forwarding, as defined in [51]. The
> color_over
> >> option may contain the keyword
> "drop" to prevent
> >> forwarding of traffic that exceeds the rate
> >> parameter.
> >>
> >> The rule syntax is a modified subset of ipfw(8)
> from FreeBSD,
> >> and the ipfw.c code may provide a useful base for
> >> implementations.
> >>
>
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------