Re: Review of draft-ietf-radext-vlan-02.txt

["Bernard Aboba" <bernard_aboba@hotmail.com>]

Let's see if we can come up with text changes to address the issues that 
we've discussed on this thread.

First off, it seems like we need to include information on what attributes 
(if any) are allowed in an Accounting-Request.  Since use in an 
Accounting-Request is not mentioned for any attributes, by default, I'd 
assume that none of the attributes are valid in an Accounting-Request, but I 
wanted to make sure this is the case.

Here is a potential rewrite of Section 2.4:

2.4.  User-Priority-Table

  Description

     [IEEE-802.1D] clause 7.5.1 discusses how to regenerate (or re-map)
     user priority on frames received at a port.  This per-port
     configuration enables a bridge to cause the priority of received
     traffic at a port to be mapped to a particular priority.
     [IEEE-802.1D] clause 6.3.9 states:

        The ability to signal user priority in IEEE 802 LANs allows
        user priority to be carried with end-to-end significance across
        a Bridged Local Area Network.  This, coupled with a consistent
        approach to the mapping of user priority to traffic classes and
        of user priority to access_priority, allows consistent use of
        priority information, according to the capabilities of the
        Bridges and MACs in the transmission path...

        Under normal circumstances, user priority is not modified in
        transit through the relay function of a Bridge; however,
        network management can control how user priority is propagated.
        Table 7-1 provides the ability to map incoming user priority
        values on a per-Port basis. By default, the regenerated user
        priority is identical to the incoming user priority.

     This attribute represents the IEEE 802 prioritization that will be
     applied to packets arriving at this port.  There are eight
     possible user priorities, according to the [IEEE-802] standard.
     [IEEE-802.1D] clause 14.6.2.3.3 specifies the regeneration table
     as 8 values, each an integer in the range 0-7.  By default, no
     remapping occurs.  The management variables are described in
     clause 14.6.2.2.

     A single User-Priority-Table attribute MAY be included in an
     Access-Accept or CoA-Request packet; this attribute MUST NOT be
     sent within an Access-Request, Access-Challenge, Access-Reject,
     Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, or
     CoA-NAK.  Since the regeneration table is only maintained by a
     bridge conforming to [IEEE-802.1D], this attribute should only be
     sent to a RADIUS client supporting that specification.

     The User-Priority-Table attribute is shown below.  The fields are
     transmitted from left to right:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |  Length       |          String
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   String
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   String            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Type

     TBD

  Length

     10

  String

     The String field is 8 octets in length, and includes a table which
     maps the incoming priority (if it is set - the default is 0) into
     one of eight regenerated priorities.  The first octet maps to
     incoming priority 0, the second octet to incoming priority 1, etc.
     The values in each octet represent the regenerated priority of the
     packet.

     It is thus possible to either remap incoming priorities to more
     appropriate values; to honor the incoming priorities; or to
     override any incoming priorities, forcing them to all map to a
     single chosen priority.

     The [IEEE-8021.D] specification, Annex G, provides a useful
     description of traffic type - traffic class mappings.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>