HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 02:34:59 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 23 Aug 1999 15:43:19 GMT ETag: "2e6a28-a455-37c16c17" Accept-Ranges: bytes Content-Length: 42069 Connection: close Content-Type: text/plain 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 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 . 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