Subject: Fwd: Re: GFR

From: Kaj Tesink <[email-masked]>
Date: Tue, 19 Oct 1999 11:27:41 -0400

hi,

attached are two traffic types to accommodate GFR
that Gary Hanson put together.

any comments?

as a matter of process, if we want to accommodate this in 2514v1.1 now
then we should not wait for the atm forum on this. so either
these types are considered very straightforward and acceptable or
if they need much more study and going back&forth with the atmf
then they'll have to wait until some future new revision of 2514v1.1

can somebody hum approval/disapproval/comment?

kaj

>Date: Mon, 11 Oct 1999 10:10:23 -0700 (PDT)
>From: "Hanson,Gary" <[email-masked]>
>To: Kaj Tesink <[email-masked]>
>Subject: Re: GFR
>
>
>Hi Kaj,
>
>Take a look at the traffic contract and conformance definition for
>GFR service in section 4.5.5, and the introduction in section 2.5.
>
>It seems clear to me that we need to add two traffic descriptor
>types, one for GFR.1 and one for GFR.2, the difference being that
>tagging is allowed in GFR.2 but not in GFR.1.  I'd suggest the
>following definitions, although we need to be sure that the IETF
>aligns the parameters, their ordering, and (ideally) the naming
>of the descriptors with the ATM Forum as the ATM Forum works to
>update its ATM-FORUM-TC-MIB:
>
>atmClpNoTaggingMcrMbsMfs  OBJECT-IDENTITY
>     STATUS  current
>     DESCRIPTION
>         "This traffic descriptor type is for CLP with
>         Minimum Cell Rate, Maximum Burst Size, Maximum
>         Frame Size, and no tagging.  The use of the
>         parameter vector for this type:
>         Parameter 1: peak cell rate in cells/second
>                      for CLP=0+1 traffic
>         Parameter 2: CDVT in tenths of microseconds
>         Parameter 3: minimum cell rate in cells/second
>         Parameter 4: maximum burst size in cells
>         Parameter 5: maximum frame size in cells
>
>         This traffic descriptor type is applicable to
>         connections following the GFR.1 conformance
>         definition."
>     REFERENCE
>         "ATM Forum, Traffic Management Specification,
>            Version 4.1, af-tm-0121.000, March 1999."
>     ::= {atmTrafficDescriptorTypes 16}
>
>atmClpTaggingMcrMbsMfs  OBJECT-IDENTITY
>     STATUS  current
>     DESCRIPTION
>         "This traffic descriptor type is for CLP with
>         Minimum Cell Rate, Maximum Burst Size, Maximum
>         Frame Size, and tagging.  The use of the
>         parameter vector for this type:
>         Parameter 1: peak cell rate in cells/second
>                      for CLP=0+1 traffic
>         Parameter 2: CDVT in tenths of microseconds
>         Parameter 3: minimum cell rate in cells/second
>         Parameter 4: maximum burst size in cells
>         Parameter 5: maximum frame size in cells
>
>         This traffic descriptor type is applicable to
>         connections following the GFR.1 conformance
>         definition."
>     REFERENCE
>         "ATM Forum, Traffic Management Specification,
>            Version 4.1, af-tm-0121.000, March 1999."
>     ::= {atmTrafficDescriptorTypes 17}
>
>Also note that the ATM Forum's ATM-FORUM-TC-MIB defines the traffic
>descriptor type atmfClpNoTaggingMcr for ABR, but the ATM-TC-MIB
>does not indicate that the corresponding traffic descriptor type
>atmClpNoTaggingMcr applies to ABR, nor does it mention TM 4.0 in
>its reference.  That should be clarified in the next revision of
>this MIB.
>
>Since their DESCRIPTION's don't mention the earlier UNI 3.0 and
>UNI 3.1 specs, and since they don't apply to them either, I'd
>remove UNI 3.0 and UNI 3.1 references from the REFERENCE clauses of
>the following traffic descriptor types, to avoid confusion:
>- atmNoClpTaggingNoScr (applies to UBR.2)
>- atmNoClpNoScrCdvt (applies to UBR.1)
>
>I'd also add a reference to the TM 4.1 spec to any traffic
>descriptor types that already refer to the TM 4.0 spec.
>
>Also, a few indentation typos that would be nice to fix in the
>draft:
>- Within AtmConnKind's DESCRIPTION, at "For Soft PVCs, an"
>- Within AtmInterfaceType's SYNTAX, at "atmfPnni1Dot0(10)"
>
>Finally, I'd remove the extra space before the period at the end of
>atmNoClpTaggingNoScr's DESCRIPTION.
>
>I hope this helps.
>
>Gary
>
>
>On Mon, 11 Oct 1999, Kaj Tesink wrote:
>
> > hi gary,
> >
> > i'm in the atmf tm spec (#121) and search for the GFR traffic descriptor;
> > found many descriptions but not a description that is snmp-usable.
> > am i looking in the right place?
> >
> > kaj
> >
> >
> >
> >
> >
> > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> >
> > Kaj Tesink
> > Telcordia Technologies (formerly Bellcore)
> > Email  [email-masked]
> > Tel    732.758.5254
> > Fax    732.758.2269
> > Postal 331 Newman Springs Rd
> >         Red Bank, NJ 07701
> >         USA
> >
> > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> >
> >
>

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies (formerly Bellcore)
Email  [email-masked]
Tel    732.758.5254
Fax    732.758.2269
Postal 331 Newman Springs Rd
        Red Bank, NJ 07701
        USA

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/