Subject: MSF SCI Req #75 and #76

From: "Aurel A. Lazar" <[email-masked]>
Date: Fri, 10 Sep 1999 15:58:17 -0400

This email represents the view of the IEEE PIN of how to satisfy in
GSMPv3 the MSF SCI requirements 75 and 76. It is being submitted
for discussion on the GSMP mailing list.

Aurel

This contribution presents the response by the IEEE P1520 (PIN)
working group on satisfying the Multiservice Switching Forum (MSF)
Switch Control Interface (SCI) requirements by the IETF GSMPv3 and the
IEEE PIN qGSMP draft protocols. It discusses how the MSF resource and
service abstraction requirements (numbers 75 and 76) are explicitly
addressed by the qGSMP protocol and can be easily incorporated into
GSMPv3. Furthermore, it shows how the QOS model in qGSMP can be
explicitly supported in GSMPv3.

1.0 Introduction

This contribution presents the response by the IEEE P1520 (PIN)
working group on satisfying the MSF SCI requirements by the IETF
GSMPv3 and the IEEE PIN qGSMP draft protocols. It discusses how the
qGSMP protocol proposed in the IEEE P1520 working group addresses the
requirements relating to the MSF resource and service abstractions
(numbers 75 and 76), and how the QOS model differences between the two
protocols can be brought into agreement.

2.0 MSF SCI Requirement #75

This requirement pertains to the IEEE PIN service abstraction:

        MSF switches and thus the SCI shall support the
        IEEE P1520 (PIN) Switch Service Abstraction

The qGSMP protocol provides the following minimal set of messages that
are sufficient to satisfy the above requirement:

  * Add Branch Message
  * Delete Branch Message
  * Add Virtual Path Message
  * Delete Virtual Path Message
  * Port Configuration Message
 ** Set Traffic Class Characterization Message
 ** Get Traffic Class Characterization Message
 ** Set QOS Constraints Message
 ** Get QOS Constraints Message

In order for GSMPv3 to explicitly support SCI requirement #75, 

 ** A service ID should be assigned for the IEEE PIN service model. 
 ** The last four messages (or the equivalent thereof) must be added
    to GSMPv3, including a description of the IEEE PIN traffic
    classes.

An alternate (but equivalent) solution that would allow GSMPv3 to
explicitly support SCI requirement #75 is proposed in Appendix A.

3.0 MSF SCI Requirement #76

This requirement pertains to the abstract resource model:

        MSF switches and thus the SCI shall support a
        Switch Resource Abstraction

The qGSMP protocol provides the following minimal set of messages that
are sufficient to satisfy the above requirement:

  * Add Branch Message
  * Delete Branch Message
  * Add Virtual Path Message
  * Delete Virtual Path Message
  * Port Configuration Message
  * All Ports Configuration Message
 ** Port QOS Configuration Message
 ** All Ports QOS Configuration Message
 ** Set Scheduling Policy Message
 ** Get Scheduling Policy Message
 ** Set Buffer Management Policy Message
 ** Get Buffer Management Policy Message

In order for GSMPv3 to explicitly support SCI requirement #76, the
last six messages (or the equivalent thereof) must be added to GSMPv3.

4.0 The IEEE PIN QOS Model

This model provides an extension to the minimal resource set given in
SCI requirement #76. The qGSMP protocol provides the following set of
messages that, together with those in section 3.0 above, are
sufficient to support the IEEE PIN QOS model.

  * Set Schedulable Region Message
  * Get Schedulable Region Message
  * Set Schedulable Region Estimator Message
  * Get Schedulable Region Estimator Message
  * Get QOS Measurements Message
  * Schedulable Region Changed Event
  * QOS Violation Event

In order to unify GSMPv3 and qGSMP, the above six messages (or the
equivalent thereof) must be added to GSMPv3 (either in the core
section or in the abstract resource model section).

Appendix A: Alternate Solution for Supporting SCI Requirement #75 in GSMPv3

An alternate solution to adding the four messages indicated in section
2.0 to GSMPv3 is to piggyback two of these messages on the Add Branch
Message and to include the other two messages in the Service
Configuration Message.

In order to adopt this approach, the following messages/ids need to be
added to GSMPv3:

 ** A service ID should be assigned for the IEEE PIN service model. 

 ** An explicit description and byte encoding of the IEEE PIN traffic
    class parameters (traffic and QOS descriptors).

 ** The Set Traffic Class Characterization Message and the Set QOS
    Constraints Message should be piggybacked on the Add Branch
    Message by including them in the Traffic Parameters Block field.

 ** The Get Traffic Class Characterization Message and the Get QOS
    Constraints Message should be included in the Service
    Configuration Message by placing them in the Capability Set
    Records. Each Capability Set ID will correspond to a traffic class
    ID.

In the Add Branch message, the Service Descriptor is structured thus: 

    1 byte - service id
    2 bytes - peak rate
    1 byte - traffic class id (capability set id)

The Traffic Parameters Block field is used only when the traffic class
description is specified (only for the first connection that belongs
to a given traffic class). For subsequent connection setups, this
field is not used.