Subject: (FRNETMIB) Adding a Priority Object to (draft-ietf-frnetmib-frs-mib-03.txt

From: "Rehbehn, Kenneth" <[email-masked]>
Date: Mon, 8 Feb 1999 12:15:52 -0500

I was a bit surprised by the proposal.  It is targeted at the port and
not the connection!  I was expecting an entry in the frPVCEndptTable to
associate a priority with a particular PVC.

Assuming that we change the object to fit into the PVC End-point Table,
we need to consider some issues.

Many implementations provide for priority using proprietary mechanisms.
The priority range may be more than 1 to 8 (I think I have heard of one
implementation supporting 24 levels of priority).  

A second issue is that priority may be asymmetric (low in one direction
and high in the other).  As an example, the proposed X.36 Frame Transfer
Priority specifies two priority fields in a new signaling information
element:  "Outgoing transfer priority index" and "Incoming transfer
priority index".  The possible priority range is 0 to 15.  The X.36
Frame Transfer Priority IE is not in the standard yet and could change,
though that is unlikely.

If we want to add priority support at this time, I suggest we follow the
ITU-T work and model the priority object as an abstract indication of
priority. Each implementation can take the MIB setting for priority (say
15 for high) and map the index into an internal implementation value for
priority.  Here is my cut at the objects:

          frPVCEndptInPriorityIndex OBJECT-TYPE
              SYNTAX  Unsigned32(0..15)
              MAX-ACCESS  read-create
              STATUS  current
              DESCRIPTION
                   "The transfer priority index value for frames
received
                    by the network (ingress).
                    
                    The transfer priority index identifies a level of
                    service where PVCs provisioned with higher values
                    receive better frame relay service than PVCs
                    provisioned with lower values. The characteristics
                    of the priority index values are implementation
                    specific and not standardized. The value serves as
                    an index from 0 (low) to 15 (high) into the
                    implementation-specific priority levels.
                    Implementations MUST support all 16 index values.

                    If a request is made using a transfer priority
                    index value that cannot be supported by the
                    network due to resource constraints, the request
                    will fail with badValue"
              DEFVAL {0}
              ::= { frPVCEndptEntry xxx }

          frPVCEndptOutPriorityIndex OBJECT-TYPE
              SYNTAX  Unsigned32(0..15)
              MAX-ACCESS  read-create
              STATUS  current
              DESCRIPTION
                   "The transfer priority index value for frames sent
                    by the network (egress).
                    
                    Refer to frPVCEndptInPriorityIndex object for a
                    description of the transfer priority index."
              DEFVAL {0}
              ::= { frPVCEndptEntry xxx }
    
Do we want to add such objects at this time?  Do we really understand
all the issues with having priority go into the MIB during Working Group
Last Call?

Ken

---------------------------------------------------------------
Ken Rehbehn                              Phone: +1-301-296-2325
Visual Networks                            Fax: +1-301-296-2302
2092 Gaither Rd                EMail: [email-masked]
Rockville, MD  20850              http://www.visualnetworks.com

> -----Original Message-----
> From: Zhongde Yu [mailto:[email-masked]]
> Sent: Friday, February 05, 1999 6:50 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: (FRNETMIB) Comments on Internet Draft
> (draft-ietf-frnetmib-frs-mib-03.txt)
> 
> 
> Dear Sir/Madam:
> 
> Attached please find our comments on the Internet Draft
> (draft-ietf-frnetmib-frs-mib-03.txt)
> regarding the possibility of adding PVC priority objects to 
> frame relay MIB.
> 
> Regards,
> 
> Zhongde Yu
> NSI Communications, Inc.
> 
> --------------------------------------------------------------
> --------------
> ---------------------
> PS: Thanks a lot for the following replies from Mr. Kenneth 
> Rehbehn and
> Mr. Andrew G. Malis.
> 
> 
> No suggestions have been made to add a priority object.  Given the
> consideration of the Frame Transfer Priority capability in Study Group
> 7, there very well may be support for adding it.
> The draft is starting Working Group last call.  I am not sure how much
> change is allowed at that stage.
> 
> Ken
> 
> 
> As Ken noted, the draft is in an advanced state of 
> development, and the
> ease of adding any new objects such as you mentioned above 
> would depend
> on whether or not you already had concrete objects you wished to
> propose, and how long this would delay the work.  The MIB just entered
> working group last call, which is the final two-week period for
> technical comments.  It is usually meant to correct errors in the MIB,
> but new objects could be considered if the working group agreed.  I
> will go ahead and add you to the list, and re-send the last call
> announcement to you.  You should send your comments, as detailed as
> possible, to the working group's email list
> ([email-masked]).
> Regards,
> 
> Andy
> FRNETMIB working group chair
> 
> 
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe frnetmib' in the body of the message.

---

From: David Fowler <[email-masked]>
Date: Mon, 08 Feb 1999 12:47:31 -0500

There are 2 types of priority that can be applied to a connection.  One is
the type of priority that Ken described below.  But, in addition, there is
a priority for the connection itself within the network.  This could be
used as follows:

When the PVC is being provisioned in the network, the priority can be used
to indicate how important the PVC is compared to other PVCs in the
network.  If there is insufficient bandwidth in the network to set up a
connection then A PVC with higher priority could, in some implementations,
supplant a PVC of lower priority in order to make room for itself.

In any case, I feel this object warrants to much discussion at this date
and I suggest that it is tabled for the next round.

David

---

From: David Fowler <[email-masked]>
Date: Mon, 08 Feb 1999 13:57:22 -0500

Someone reminded me that the word tabled is ambiguous (Thanks, Randy).

What I meant is we should put forward the current I-D without adding a
priority object and discuss a priority object if/when the WG re-activates.

Regards,
David