Re: [Disman] pingCtlDSField in remops

["Randy Presuhn" <[e-mail]>]

Hi -

> From: "Romascanu, Dan (Dan)" <[e-mail]>
> To: "Randy Presuhn" <[e-mail]>; <[e-mail]>
> Sent: Saturday, July 09, 2005 11:12 PM
> Subject: RE: [Disman] pingCtlDSField in remops
>
> 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-sspm-mib-12.txt.
...

Unfortunately,  sspmSourceProfileTOS is an OBJECT-TYPE, not a TC.

Randy

Dan


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Randy Presuhn
> Sent: Sunday, July 10, 2005 3:59 AM
> To: [e-mail]
> Subject: [Disman] pingCtlDSField in remops
>
> Hi -
>
> > From: "Juergen Quittek" <[e-mail]>
> > To: <[e-mail]>; "Juergen Quittek"
> > <[e-mail]>
> > Cc: <[e-mail]>
> > 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
>
>
>
>
>