RE: pingCtlDSField in remops

Implementations of RFC 2925 take the value of the pingCtlDSField object
and write it to the TOS / Traffic Class octet, because as defined in
RFC 2474 the DiffServ Field originally had a length of 8 bits.

If we want to maintain compatibility with implementations of RFC 2925,
then we should not focus on strictly following the DSField definiton,
that was shortened to 6 bits by RFC 3260.

Rather, the DESCRIPTION clause should just state that the value of the
octet is copied into the TOS / Traffic Class octet, for example

 pingCtlDSField OBJECT-TYPE
    SYNTAX      Unsigned32 (0..255)
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Specifies the value to store in the Type of Service
        (TOS) octet in the IPv4 header or in the Traffic
        Class octet in the IPv6 header, respectively, of the
        IP packet used to encapsulate the ping probe.

        The octet to be set in the IP header contains the
        Differentiated Services (DS) Field in the six most
        significant bits.

        This option can be used to determine what effect an
        explicit DS Field setting has on a ping response.
        Not all values are legal or meaningful.  A value of 0
        means that the function represented by this option is
        not supported.  DS Field usage is often not supported
        by IP implementations and not all values are supported.
        Refer to RFC 2474 and RFC 3260 for guidance on usage of
        this field."
    REFERENCE
        "Refer to RFC 1812 for the definition of the IPv4 TOS
        octet and to RFC 2460 for the definition of the IPv6
        Traffic Class octet.  Refer to RFC 2474 and RFC 3260
        for the definition of the Differentiated Services Field."
    DEFVAL { 0 }
    ::= { pingCtlEntry 22 }


Thanks,

    Juergen Q.
-- 
Juergen Quittek        [email protected]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

--On 7/10/2005 9:12 AM +0300 Romascanu, Dan (Dan) wrote:

> If there is a need for a Dscp semantics only TC, why not use Dscp or
> DscpOrAny from DIFFSERV-DSCP-TC (RFC 3289) which is imported by other
> MIB modules. Alternatively, if the semantics covers the whole TOS
> object, I would prefer to see a less Ping MIB oriented name and
> semantics, that the TC could be imported for more generic TOS purposes,
> like the sspmSourceProfileTOS in
> http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-rmonmib-ssp
> m-mib-12.txt.
>
> Regards,
>
> Dan
>
>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of Randy Presuhn
>> Sent: Sunday, July 10, 2005 3:59 AM
>> To: [email protected]
>> Subject: [Disman] pingCtlDSField in remops
>>
>> Hi -
>>
>> > From: "Juergen Quittek" <[email protected]>
>> > To: <[email protected]>; "Juergen Quittek"
>> > <[email protected]>
>> > Cc: <[email protected]>
>> > Sent: Saturday, July 09, 2005 4:44 PM
>> > Subject: Re: [Disman] Re: MIB Doctor review:
>> > publishdraft-ietf-disman-remops-mib-v2-06.tx t
>> ...
>> > Here is something that should be compatible with the old definition:
>> >
>> > OLD
>> >  pingCtlDSField OBJECT-TYPE
>> >     SYNTAX      Unsigned32 (0..255)
>> >     MAX-ACCESS  read-create
>> >     STATUS      current
>> >     DESCRIPTION
>> >         "Specifies the value to store in the Differentiated
>> >         Services (DS) Field in the IP packet used to
>> >         encapsulate the ping probe.  The DS Field is defined
>> >         as the Type of Service (TOS) octet in a IPv4 header
>> >         or as the Traffic Class octet in a IPv6 header.
>> >
>> >         The value of this object must be a decimal integer
>> >         in the range from 0 to 255.  This option can be used
>> >         to determine what effect an explicit DS Field setting
>> >         has on a ping response.  Not all values are legal or
>> >         meaningful.  A value of 0 means that the function
>> >         represented by this option is not supported.  DS Field
>> >         usage is often not supported by IP implementations and
>> >         not all values are supported.  Refer to RFC 2474 for
>> >         guidance on usage of this field."
>> >     REFERENCE
>> >         "Refer to RFC 2474 for the definition of the
>> >         Differentiated Services Field and to RFC 1812
>> >         Section 5.3.2 for Type of Service (TOS)."
>> >     DEFVAL { 0 }
>> >     ::= { pingCtlEntry 22 }
>> > NEW
>> >  pingCtlDSField OBJECT-TYPE
>> >     SYNTAX      Unsigned32 (0..255)
>> >     MAX-ACCESS  read-create
>> >     STATUS      current
>> >     DESCRIPTION
>> >         "Specifies the value to store in the Differentiated
>> >         Services (DS) Field in the IP packet used to
>> >         encapsulate the ping probe.  The DS Field is defined
>> >         as the first 6 bits of the Type of Service (TOS) octet
>> >         in the IPv4 header or as the first 6 bits of the
>> >         Traffic Class octet in the IPv6 header, respectively.
>> >
>> >         This option can be used to determine what effect an
>> >         explicit DS Field setting has on a ping response.
>> >         Not all values are legal or meaningful.  A value of 0
>> >         means that the function represented by this option is
>> >         not supported.  DS Field usage is often not supported
>> >         by IP implementations and not all values are supported.
>> >         Refer to RFC 2474 and RFC 3260 for guidance on usage of
>> >         this field.
>> >
>> >         The value of pingCtlDSField corresponds to the value
>> >         of the TOS octet or the Traffic Class Octet,
>> >         respectively.  This implies that it has to be divided
>> >         by 4 (or bitwise shifted right by 2) in order to
>> >         extract the encoded DS Field value."
>> >     REFERENCE
>> >         "Refer to RFC 2474 and RFC 3260 for the definition of
>> >         the Differentiated Services Field."
>> >     DEFVAL { 0 }
>> >     ::= { pingCtlEntry 22 }
>> ...
>>
>> The added text makes it sound like this object is only about
>> the DSCP, rather than the entire TOS octet.  I think this
>> matters because the two bit positions that RFC 2474 and 3260
>> call "currently unused" that are in fact used by RFC 3168 for ECN.
>>
>> With perfect foresight we should have made this into two
>> objects, but we didn't.  I think the next best thing is to
>> say that the six high bits go to the DSCP, and the two low
>> bits go to the ECN field, which would be more consistent with
>> this object's original definition in terms of the TOS octet,
>> rather than just talking about DSCPs.
>>
>> I suggest adding text and a reference to RFC 3168 for the two
>> low-order bits.
>>
>> Randy
>>
>>
>>
>>
>>
>