[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
GSMP Working Group                                    Kenneth Sundell
Internet-Draft                                        Nortel Networks
                                                           Avri Doria
Expiration Date: Feb 20, 2000                                   Nokia
                                                      20 August, 1999

            GSMP WG response to MSF SCI Requirements
             <draft-ietf-gsmp-msf-response-00.txt>


Status of this Memo

     This document is an Internet-Draft and is in full conformance
     with all provisions of Section 10 of RFC2026.

     Internet-Drafts are working documents of the Internet
     Engineering Task Force (IETF), its areas, and its working
     groups.  Note that other groups may also distribute working
     documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-
     Drafts as reference material or to cite them other than as
     "work in progress."

     The list of current Internet-Drafts can be accessed at:
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed
     at:  http://www.ietf.org/shadow.html.

     Distribution of this memo is unlimited.

     Copyright Notice

     Copyright (C) The Internet Society (1999).  All Rights
     Reserved.


Abstract

This document is the IETF GSMP Working Group response to "Service
Control Interface Requirements" submitted by the Multiservice
Switching Forum Switch Control Working Group as <draft-mceachern-
gsmp-scireq-00.txt>. This document compares the capabilities of the
GSMPv3 against the MSF SCI requirements. It also invites



INTERNET-DRAFT..GSMP WG response to MSF SCI Requirements  20.08.99



Sundell, Doria               Expires Feb 2000               [Page 2]


contributions from individuals of MSF on meeting any unresolved
requirements.


1.  Introduction

The Multiservice Switching Forum (MSF) is a body dedicated to
arriving at implementation agreements that satisfy the needs of
carriers offering multiservice networks. MSF has, by its liaison,
submitted a set of requirements on a switch control interface stated
in [5] to the GSMP working group. The reason for the liaison is that
the MSF has decided to use GSMPv3 as their base switch control
protocol and now wants to be sure that their original requirements
will be supported by GSMP. During the 45th IETF meeting in Oslo a
consensus was reached on the notion that support of the requirements
was definitely within the GSMP WG interest, and that the WG supported
this goal.

This documents compares the capabilities of the GSMPv3 [3] against
the MSF SCI requirements stated in [5]. Four different ratings are
used to give a rough understanding of the level of conformance.

S: requirement believed to be satisfied

PS: requirement believed to be partially satisfied

NS: requirement believed not to be satisfied

E: requirement needs further explanation

PE:      requirement is pending (e.g. waiting for GSMP working Group
         action or IESG resolution)

One objective of this document is to request further explanations on
requirements that were not adequately understood. It also requests
MSF contributions, in the form of either I-Ds or WG mail list
discussions, on ways to resolve issues in the categories `PS', `NS'
and `E' in the list above. This document has been reviewed on the
GSMP WG mailing list for rough consensus before being presented to
the MSF body as an MSF contribution.


2.  Terminology
       SCI:      Switch Control Interface. The interface used between a
                 VSC (SCI Master) and a VS (SCI Slave).




INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 3]


   SCP:      Switch Control Protocol. SCP is the protocol that
             realises
             the SCI.

   VS:       Virtual Switch. VS is an arbitrary subset of switch
             resources that can be controlled as a unit through a
             single
             SCI slave. The switch resources that make up a Virtual
             Switch can come from a single switch, or a group of
             physically connected switches.

   VSCE:     Virtual Switch Controller Entity. VSCE is an active
             software/hardware entity that implements all or part of
             an SCI master and exerts control over a VS by
             communicating with its SCI Slave.

   VSC:      Virtual Switch Controller. VSC is A set of one or more
             VSCE, which together control the resources of a VS. A
             VSC implements the Switching and Bearer Control Function
             for a given service.



3.  Switch Control Interface Requirements

This section lists the MSF requirements in the same order as in [4].
The believed level of conformance to GSMPv3 is stated as defined in
the introduction section of this document.

3.1  Fundamental Requirements

The SCI shall allow the control of ATM switching and adaptation
functions for the following services over an ATM capable core:

Requirement #66:         Support for ATM service

GSMPv3 compliance:       S. requirement believed to be satisfied.
                         The requirement was already supported in GSMPv2
                         and will be retained in GSMPv3.

Requirement #67:         Support for Frame Relay service

GSMPv3 compliance:       PS. requirement believed to be partially
                         satisfied.
                         The GSMP WG charter includes support for frame
                         relay switches. So far only frame relay
                         services are identified. Contributions are



INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 4]


                       needed for describing what is needed for
                       supporting frame relay switches as well as for
                       allowing the control of ATM switching and
                       adaptation functions for frame relay services
                       over an ATM capable core.

                       It should be noted that GSMPv3 does not include
                       support for translating (adapting) from Frame
                       Relay to ATM label types or support for
                       translating from frames to cells.  It is also
                       not clear whether such capabilities are
                       considered with the scope of GSMP or whether
                       they belong to another protocol mechanism, for
                       example either a network or policy management
                       mechanism.

Requirement #68:       Support for Circuit Emulation Service

GSMPv3 compliance:     NS. requirement believed not to be satisfied.
                       E.  requirement needs further explanation
                       CE Service is not supported in GSMPv3. There is
                       also a need for further specification of this
                       requirement, as the WG did not have a clear
                       idea of the requirements for supporting circuit
                       emulation services.

Requirement #69:       Support for MPLS service

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       See ref. [3].  Support for MPLS services is the
                       primary chartered requirement for the GSMP
                       working group and as such is an ongoing focus
                       for the WG.


3.2  Switch Partitioning Requirements

The SCI shall allow separate VSCs to control the VSs of a partitioned
MSS switch.

Requirement #4:     partition a MSS into multiple VSs

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       The partition identifier was introduced in
                       draft-ietf-gsmp-00.txt in order to support
                       partitioning. The partitioning function itself,
                       however, is not considered to be part of GSMP.



INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 5]


Requirement #17:  static/deterministic partitioning

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       Static partitioning is supported in [3]; i.e.
                       the partition has to be done before running
                       GSMP.

Requirement #18:       dynamic/statistical partitioning

GSMPv3 compliance:     PS. requirement believed to be partially
                       supported.
                       While physical resources can be statistical
                       shared among partitions, there is no support
                       for dynamic partitioning.

Requirement #19:       The controller sees and controls its own
resources

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       The partition identifier was introduced in
                       draft-ietf-gsmp-00.txt.  It is a requirement
                       that a partition's resources be available only
                       to that partition's VSC.


3.3  Resource and Service Model Requirements

Requirement #73:       MSF switches and thus the SCI shall support an
                       ATM Forum Switch Service Abstraction

GSMPv3 compliance:     S. requirement believed to be satisfied.
               See [3].

Requirement #74:       MSF switches and thus the SCI shall support
                       an MPLS Switch Service Abstraction

GSMPv3 compliance:     S. requirement believed to be satisfied.
               See [3].

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

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       The switch service abstraction model specified
                       in [6] is allowed for usage in GSMP, though it
                       will not be part of the GSMPv3 specification.
                       See chapter 2.1 "Changes to the system
                       configuration request message" in [4], which


INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 6]


                       will part of the next revision of [3]
                       A suggestion has been made that GSMPv3 should
                       include this abstraction in the base protocol.
                       This would need to be recommended formally to
                       the WG, and then discussed at the next IETF
                       meeting. It is the co-authors' opinion,
                       however, that the requirement is satisfied by
                       including support for the IEEE Service model as
                       an optional extension.

Requirement #76:       MSF switches and thus the SCI shall support a
                       Switch Resource Abstraction

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       The optional Abstract and Resource Model [4]
                       was approved at the Oslo meeting and will be
                       part of an updated version of [3].  This
                       mechanism allows for a partition to negotiate
                       the use of a resource abstraction.  Currently
                       there are two such abstractions available:, the
                       abstraction defined by qGSMP and the
                       abstraction defined in Chapter 9 of GSMPv2 [2].
                       A suggestion has been made that GSMPv3 should
                       include this resource model in the base
                       protocol. This would need to be recommended
                       formally to the WG, and then discussed at the
                       next meeting. It is the co-authors' opinion,
                       however, that the requirement is satisfied by
                       including support for the IEEE resource model
                       as an optional extension.

Requirement #78:       The SCI shall allow the VSC to discover the
                       switch
                       resource abstraction supported by the VS

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       The Abstract and Resource Option negotiation
                       mechanism contained in [4] was approved at the
                       Oslo meeting and will be part of the updated
                       version of [3].

Requirement #79:       The SCI shall be extensible to allow new
                       service
                       and resource abstractions.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       The [4] was approved at the Oslo meeting and
                       will be part of the updated version of [3].



INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 7]


Requirement #21:       The SCI shall not prevent over-subscription of
                       resources, such as bandwidth.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       Over-subscription of resources is not
                       prevented, though there are no provisions to
                       specifically support and track over-
                       subscription of resources.


3.4  Architectural Requirements

Requirement #80:       The SCI shall provide a standard mechanism for
                       inclusion of vendor-proprietary extensions

GSMPv3 compliance:     PS. requirement believed to be partially
                       supported.
                       GSMP today allows proprietary extensions in the
                       end of the message, that is, everything after
                       the last "GSMP message field" is considered as
                       available for proprietary information. There is
                       a question on whether this is enough or whether
                       an extra field that flags for additional
                       information such as records, objects or TLV's
                       should be included.  Opinions and contributions
                       are invited on this issue.

Requirement #1:        A VS shall be controlled by only one VSC at any
                       given time.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       A partition identifier is included in [3] and
                       GSMP only allows a single VSC to control a
                       switch partition.

Requirement #2:        A VSC can be composed of an arbitrary number of
                       VSCEs and a VS can be composed of the resources
                       of an arbitrary number of physical switches.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       The partition identifier will not limit the
                       number of physical elements within either the
                       VS or the VSC. The protocol, does, however,
                       require that there be only one control channel
                       between the VSC and the VS.

Requirement #5:        The SCI shall be able to support a VSC that is
                       composed of multiple active VSCEs, all of which


INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 8]


                       can issue SCI requests simultaneously to the
                       same VS. The VS is not responsible for co-
                       ordination of the VSCEs.

GSMPv3 compliance:     NS. requirement believed not to be satisfied.
                       There is currently no support for redundant
                       controllers in [3]. In order to fulfil this
                       requirement proposals are needed.

Requirement #6:        It shall be possible for the VSCEs that make up
                       aVSC to run on physically separate platforms and
                       to
                       access the VS over separate physical paths
                       (links).

GSMPv3 compliance:     NS. requirement believed not to be satisfied.
                       There is currently no support for multiple
                       control channels in [3]. In order to fulfil
                       this requirement proposals are needed.

Requirement #55:       The SCI may support redundant physical
                       connectivity between a VSCE and a VS.

GSMPv3 compliance:     NS. requirement believed not to be satisfied.
                       There is currently no support for redundant
                       controllers in [3]. In order to fulfil this
                       requirement proposals are needed.

Requirement #57:       The SCI should not be the limiting constraint
                       on
                       the number of connections concurrently active
                       on a switch.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       The GSMPv3 does not impose a limiting
                       constraint.

Requirement #58:       The SCI should not restrict the number of
                       virtual
                       ports.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       The GSMPv3 does not include any restrictions on
                       the number of ports other then restriction by
                       virtue of field size.





INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 9]


Requirement #59:       The SCI shall not restrict the physical
                       interface
                       types supported by the switch.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       The GSMPv3 does not include any restrictions on
                       physical interface types, though only a limited
                       number of types are currently defined.

Requirement #60:       The SCI shall allow support for at least one
                       terabit/second throughput per virtual port. The
                       SCI encoding of bandwidth values shall be
                       extensible, and shall include those specified
                       by ATM Forum.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       No restrictions are identified in [3].

Requirement #61:       The SCI shall allow a VSC to have multiple
                       outstanding requests (e.g., to support high
                       call rates).

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       Outstanding request messages are associated
                       with the corresponding response messages by a
                       transaction identifier.  This allows for
                       support of multiple request messages.


3.5  Fault Tolerance and Synchronization Requirements

Requirement 8#:        The SCI shall not restrict the switch
                       redundancy
                       scheme and must allow for m:n hardware level
                       redundancy in the switch (e.g., Card level
                       redundancy, other component level switching,
                       APS on interfaces).

GSMPv3 compliance:     PS. requirement believed to be partially
                       satisfied.
                       E.  requirement needs further explanation.
                       There are no mechanisms in GSMPv3, which
                       restrict hardware level redundancy.  There are
                       also no mechanisms, which support such
                       redundancy.  This requirement needs further
                       clarification in order to understand whether




INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 10]


                       such a passive lack of restrictions meets the
                       requirement.

Requirement #9:        The SCI shall provide a mechanism for detecting
                       loss of synchronization of state (consistency
                       of state between VSC and VS). The mechanism
                       must be able to detect whether or not the
                       switch has the same configuration (including
                       connections, connection configuration
                       parameters and switch configuration parameters)
                       that the VSC has sent into it.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       This is currently done by checking on the state
                       of each connection. Recommendations for better
                       mechanisms are invited.

Requirement #10:       In order to be scalable, the SCI must provide a
                       recovery mechanism that does not disrupt
                       unaffected connections. The recovery mechanism
                       must be able to resynchronize only the part of
                       the state that is related to the failure

GSMPv3 compliance:     PS. requirement believed to be partially
                       satisfied
                       While non-disruptive recovery is supported, the
                       recovery might not be fast enough for specific
                       configurations, e.g. switches with a large
                       number of ports. The GSMP utilises port by port
                       recovery. Recommendations for better mechanisms
                       are invited.

Requirement #11:       The SCI shall support hitless redundant VSCE
                       switchover: A redundant VSCE should be able to
                       assume control of the VS without disrupting
                       existing user plane connections.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       The adjacency mechanism includes a flag, which
                       indicates that prior state should be retained
                       even though a new adjacency has been
                       established.

Requirement #12:       The SCI should be able to operate properly over
                       an
                       unreliable interconnect or network.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       See 2.3 "TCP/IP Encapsulation" in [3].


INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 11]


                       Additionally, mechanisms are provided which
                       require optional acknowledgement of every
                       command.

Requirement #64:       The SCI shall support hitless resynchronization
                       between the VSC and the VS when they are
                       already in sync. Some examples of
                       resynchronization when the VSC and VS are in
                       sync are:

                       -  Resynchronization after VSC rebuild

                       -  Resynchronization after VSC
                         upgrades/downgrades

                       -  Resynchronization after switch component
                         switchover

                       -  Resynchronization after switch component
                         rebuild

                       -  Resynchronization after switch component
                         upgrade/downgrade

GSMPv3 compliance:     E. requirement needs further explanation.
                       In order to understand the requirement examples
                       should be provided by MSF. While GSMP doesn't
                       prevent such activities, it doesn't support
                       explicitly them either.


Requirement #65:       The VSC shall be allowed to submit new SCI
                       requests which affect VS state
                       (e.g., establish new connections, delete
                       existing connections) while resynchronization
                       is being performed, after re-establishment of
                       the association between the VSC and the VS.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       GSMP requires resynchronization in two steps.
                       While step 1, adjacency, is being taken care
                       of, no commands are accepted. After adjacency
                       any command is accepted, even if state
                       coherency is being checked at the time.






INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 12]


3.6  Security Requirements

Requirement #13:       The SCI shall allow the VSC and VS to
                       authenticate
                       each other's identity using a standard
                       authentication protocol (e.g., IPSec, ATM
                       Forum)

GSMPv3 compliance:     PE. requirement is pending.
                       The level of security is a subject for
                       discussion in several IETF working groups. The
                       issue has been addressed to the IESG to be
                       resolved. A mechanism has been suggested within
                       the group that may not be adequate for IETF
                       security purposes.  It is possible that use if
                       IPSec will be mandated for security purposes
                       when using the IP encapsulation.
                       In terms of the ATM Encapsulation, the security
                       mechanism reportedly is taken care of during
                       connection establishment of the control
                       channel, so there should be no change required
                       to GSMP to support ATM security.

Requirement #14:       The SCI shall allow for secure communication
                       between VSC and VS using a standards based
                       security protocol

GSMPv3 compliance:     PE. requirement believed to be satisfied.
                       The level of security is a subject for
                       discussion in several IETF working groups. The
                       issue is addressed to the IESG to be resolved.
                       A mechanism has been suggested with the group
                       that may not be adequate for IETF security
                       purposes.  It is possible that use if IPSec
                       will be mandated for security purposes when
                       using the IP encapsulation.
                       In terms of the ATM Encapsulation, the security
                       mechanism reportedly is taken care of during
                       connection establishement of the control
                       channel, so there should be no change required
                       to GSMP to support ATM security.









INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 13]


3.7  Functional Requirements

3.7.1 Virtual Switch Configuration and Management

Requirement #20:       The SCI shall allow the VS to display its
                       resources to a VSC in a generic way.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                See chapter 7 "Configuration message" in [3].

Requirement #25:       The SCI shall allow the VSC to discover the VS
                       capabilities in a generic way.

GSMPv3 compliance: S. requirement believed to be satisfied.
                See chapter 7 "Configuration message" in [3].


3.7.2 Connection Control

Requirement #32:       The SCI shall allow the VSC to add, delete, and
                       verify connections within its VS.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       See chapter 4 "Connection Management Messages"
                       in [3].

Requirement #33:       The SCI shall allow the VSC to modify
                       connections
                       within its VS.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       See chapter 4 "Connection Management Messages"
                       in [3].

Requirement #34:       The SCI shall support point to point
connections.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       See chapter 4 "Connection Management Messages"
                       in [3].

Requirement #35:       The SCI shall support point to multipoint
                       connections.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       See chapter 4 "Connection Management Messages"
                       in [3].


INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 14]


Requirement #36:       The SCI shall support multipoint to point
                       connections.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       See chapter 4 "Connection Management Messages"
                       in [3].

Requirement #38:       The SCI shall support virtual channel and
                       virtual
                       path connections.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       See chapter 4 "Connection Management Messages"
                       in [3].

Requirement #39:       The SCI shall support the termination of
                       virtual
                       paths (splitting a VP into VCs) as per I.311.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       Since gsmp is not directly involved in any ATM
                       signaling issues there is only the cell
                       switching to consider. GSMP supports VPC
                       termination in exactly the same way that it
                       supports cell switching on the VPI/VCI. GSMP
                       makes no distinction here.
                       For example, lets take a simple scenario, using
                       a terminology of (port:vpi:vci->port:vpi:vci)
                       to represent GSMP branches. Now, let's add the
                       following:
                         (2:0:40->5:20:1)  and  (5:20:1->2:0:40)
                         (7:0:51->5:20:2)  and  (5:20:2->7:0:51)
                         (8:0:77->5:20:3)  and  (5:20:3->8:0:77)
                       at the switch adjacent to this one's port 5, we
                       then switch the VPI=20 as a VPC, e.g. we add
                       VPC branches (5:20:*->12:18:*) and (12:18:*-
                       >5:20:*). As far as cell switching is concerned
                       we have terminated the VPC. From GSMP's point
                       of view, VPC termination is no different from
                       VCC switching. So while VPC termination is not
                       explicit in the protocol, it is supported.

Requirement #41:       The SCI shall allow the VSC to specify traffic
                       and
                       QoS parameters for each connection.

GSMPv3 compliance:     S. requirement believed to be satisfied.
               See chapter 9 "Service Model Definition" in [3].



INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 15]


3.7.3  Exception Notification

Requirement #49:       The SCI should contain the vocabulary for the
                       switch to notify VSCs of asynchronous events
                       occurring in the switch that affect their VS.
                       The minimal set of traps is:

                       -  Interface up of down

                       -  Change in available interfaces

                       -  Interface faults

                       -  Switching faults

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       See chapter 8 "Event Messages" in [3].

Requirement #50:       The SCI shall provide a flow control mechanism
                       for
                       asynchronous event notifications.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       In [3] an event flag is used for each type of
                       event messages corresponding to a switch port.
                       Event flags together with an event sequence
                       number, forms a simple flow control scheme
                       preventing the switch from flooding the
                       controller with event messages.
                       See chapter 8 "Event Messages" [3].
                       Suggestions for other mechanisms are invited.


Requirement #51:       The SCI shall provide a mechanism for filtering
                       asynchronous event notifications.

GSMPv3 compliance:     S. requirement believed to be satisfied.
               See chapter 5 "Port Management messages" in [3].
               Suggestions for other mechanisms are invited.


3.8  SCI Protocol Implementation Requirements

Requirement #52:       The SCP shall be capable of operating over ATM

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       See chapter 2.1 "ATM encapsulation" in [3]


INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 16]


Requirement #54:       The SCP shall be capable of operation over IP.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       See chapter 2.3 "TCP/IP Encapsulations" in [3].

Requirement #56:       The SCP should work as a remote protocol.

GSMPv3 compliance:     S. requirement believed to be satisfied.
                       It is not noted explicitly in [3] but GSMP may
                       be used remotely.


3.9  Management Requirements

The management requirements are not considered as MSF SCI
requirements. The MSF Switch Control working group has not yet agreed
upon which of these requirements do indeed apply to the SCI and
intends to clarify these requirements in a future I-D. The compliance
check to these requirements will be done in a future revision of this
draft when the results from MSF have been received.

The GSMP group is, however, chartered to produce a GSMP MIB.  Some of
these requirements may be met within such a MIB.  Alternatively,
future GSMP work not currently chartered may include work towards
dynamic policy management of a switch's resources.  It is possible
that some of these management requirements may fit into such work
once it has been defined and approved by the IESG.

In any case, all of the management requirements need further
definition and explication.

3.9.1 Resource and Service Model Requirements

Requirement #22:       The SCI shall allow the VSC to associate
                       subsets of the resources assigned its VS to
                       service classes offered by the VS.

Requirement #77:       The management interface for creating VSs shall
                       allow the user to choose from a set of offered
                       switch resource abstractions.

3.9.2 Virtual Switch Configuration and Management

Requirement #26:       The SCI shall allow the VSC to read and write
                       VS
                       configuration parameters.



INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 17]


                      Examples include:

                      -  Assigning bandwidth to classes of service

                      -  Setting flow control parameters for the SCI


3.9.3 Virtual Port Configuration and Management

Requirement #27:      The SCI shall allow a virtual port to be
                      brought
                      in to service or taken out of service.

Requirement #28:      The SCI shall allow the VSC to reset a virtual
                      port that belongs to its VS.

Requirement #29:      The SCI shall allow the VSC to configure
                      rudimentary test states.

Requirement #30:      The SCI shall allow the VSC to set the
                      bandwidth
                      of a virtual port.

Requirement #31:      The SCI may allow the VSC to establish and
                      manipulate label ranges per virtual port.


3.9.4 State and Statistics Reporting

Requirement #42:      The SCI shall allow the VSC to read counters
                      associated with VS input and output virtual
                      ports.

Requirement #43:      The SCI shall allow the VSC to read counters
                      associated with virtual path and virtual
                      channel connections.

Requirement #44:      The SCI shall allow the VSC to read individual
                      switched connection state. Connection states
                      include following: does-not-exist, exists,
                      exists-failed.

Requirement #45:      The SCI shall allow the VSC to perform bulk
                      reads
                      of statistics for all connections on a



INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 18]


                     specified virtual path or a specified virtual
                     port.

Requirement #46:     The SCI may allow the VSC to collect data for
                     performance monitoring, account management, and
                     other statistics on request or at present
                     intervals.

Requirement #47:     The SCI shall allow the VSC to collect
                     statistics
                     for a single connection or for groups of
                     connections for efficient scaling.

Requirement #48:     The detailed list of required statistics should
                     include the BICI statistics for ATM and other
                     statistics types for other services.



4.  Conclusion

It seems that the majority of the requirements are already supported
by the work done in [1] and [2] together with the efforts done in the
GSMP working group in producing GSMPv3[3]. There are, however, still
some requirements that not met or are only partially by what is
currently included in GSMPv3. The GSMP WG encourages contributors to
fill these holes in order to get them into an updated version of
GSMPv3[3]. The most effective way of doing this is by submitting I-
D's or using the GSMP mailing list for the purpose.


Requirements believed to be satisfied:
66, 69, 4, 17, 19, 73, 74, 75, 76, 78, 79, 21, 1, 2, 57, 58, 59, 60,
61, 9, 11, 12, 65, 20, 25, 32, 33, 34, 35, 36, 38, 39, 41, 49, 50,
51, 54, 56

Requirements believed to be partially satisfied:
67, 18, 80, 8, 10

Requirements not believed to be supported:
68, 5, 6, 55

Requirements that need further explanation:
8, 64, 68, 52

Requirements that are pending:
13, 14


INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 19]


Authors' Contact

   Kenneth Sundell
   Nortel Networks
   Architecture Lab, EMEA
   Kungsgatan 34, PO Box 1788
   111 97 Stockholm, Sweden
   Phone +46 8 441 7838
   Mobile +46 70 665 7838
   ksundell@nortelnetworks.com


   Avri Doria
   Nokia Telecommunications
   3 Burlington Woods Drive, Suite 250
   Burlington, MA 01803
   Phone: +1 781 359 5131
   Mobile: +1 617 678 9402
   avri.doria@nokia.com


   Comments on this document should be sent to the authors or to the
   working group mailing list at gsmp@psyton.com.



References

[1]  Newman, P., Edwards, W., Hinden, R., Hoffman, E, Ching Liaw,
     F., Lyon, T. and Minshall, G., "Ipsilon's General Switch
     Management Protocol Specification," Version 1.1, RFC 1987,
     August 1996.

[2]  Newman, P., Edwards, W., Hinden, R., Hoffman, E., Ching
     Liaw, F., Lyon, T. and Minshall, G., "Ipsilon's General
     Switch Management Protocol Specification," Version 2.0, RFC
     2397, March 1998.

[3]  GSMP Working Group, Tom Worster Editor, "General Switch
     Management Protocol V3", draft-ietf-gsmp-00.txt, June, 1999




INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99



Sundell, Doria               Expires Feb 2000               [Page 20]

[4]  GSMP Working Group, Doria, A., Hellstrand, F. and Adams, C.
     "An optional abstract and resource model",
     draft-doria-gsmp-arm-01.txt, June, 1999

[5]  MSF Switch Control WG, McEachern, J, "Service Control
     Interface Requirements Multiservice Switching Forum",
     draft-mceachern-gsmp-scireq-00.txt, June, 1999

[6]  IEEE/WG 1520, Adam, C., Lazar, A. and Nandikesan, M.,
     "The qGSMP protocol", draft-adam-gsmp-qgsmp-00.txt, June,
     1999


This document expires on 20 February 2000.
































INTERNET-DRAFT    GSMP WG response to MSF SCI Requirements   20.08.99