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
