draft-ietf-gsmp-applicability-01.txt   draft-ietf-gsmp-applicability-02.txt 
INTERNET DRAFT Avri Doria A new Request for Comments is now available in online RFC libraries.
GSMP Working Group Kenneth Sundell
Informational Track Nortel Networks
July 2000
General Switch Management Protocol Applicability
<draft-ietf-gsmp-applicability-01.txt>
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.
Abstract
This memo provides an overview of the GSMP protocol and includes
information relating to its deployment in a MPLS environment.
1. Overview
The General Switch Management Protocol (GSMP) has been available
to the IETF community for several years now as informational
RFC's. Both GSMPv1.1 released in March 1996 as RFC1987 [2], and
GSMPv2.0 released in August 1998 as RFC2297 [3] are available.
Several vendors have implemented GSMPv1.1.
In V1.1 and V2 GSMP was intended only for use with ATM switches.
During the course of the last year, the GSMP working group has
decided to expand the purview of GSMP to the point where it can be
used to control a number of different kinds of switch and can thus
live up to what its name indicates; a general switch management
protocol. To do this, commands and arguments needed to be
generalised, with sections added discussing the manner in which
the generalised protocol could be applied to specific kinds of
switches and port types. In short the protocol has gone through
major changes in the last 24 months.
GSMP provides an interface that can be used to separate the data
forwarder from the routing and other control plane protocols such
as LDP. As such it allows service providers to move away from
monolithic systems that bundle control plane and data plane into a
single tightly coupled system - usually in a single chassis.
Separating the control components from the forwarding components
and using GSMP for switch management, enables service providers to
create multi-service systems composed of various vendors
equipment. It also allows for a more dynamic means of adding
services to their networks.
The IETF GSMP working group was established in the routing area
because GSMP was being seen as an optional part of the MPLS
solution. In a MPLS system, it is possible to run the routing
protocols and label distribution protocols on one system while
passing data across a generic switch, e.g. an ATM switch. GSMP
provides the switch resource management mechanism needed in such a
scenario.
GSMP has also been selected by the Multiservice Switching
Forum(MSF) as its protocol of choice for the Switch Control
Interface identified in their architecture. The MSF is an
industry forum, which among its activities establishes their
member's requirements and then works with the appropriate
standards bodies to foster their goals. In the case of GSMP, the
MSF presented the IETF GSMP Working Group with a set of
requirements for GSMP. The working group has made a determined
effort to comply with those requirements in its specifications.
2. GSMP V3 Document Set
The current version of GSMP is documented in 3 documents:
- GSMP: General Switch Management protocol V3 [5]
- GSMP-ENCAPS: GSMP Packet Encapsulations for ATM, Ethernet
and TCP[4]
- GSMP-MIB: Definitions of Managed Objects for the General
Switch Management Protocol [1]
3. General Description
The General Switch Management Protocol V3 (GSMPv3) [5], is a
general purpose protocol to control a label switch. GSMP allows
a controller to establish and release connections across the
switch; add and delete leaves on a multicast connection;
reserve resources; manage switch ports; request configuration
information; and request statistics. It also allows the switch
to inform the controller of asynchronous events such as a link
going down. The GSMP protocol is asymmetric, the controller
being the master and the switch being the slave.
A physical switch can be partitioned in many virtual switches.
GSMP does not provide support for defining switch partitions.
GSMP treats a virtual switch as if it were a physical switch.
GSMP may be transported in three ways:
- GSMP operation across an IP network is specified.
- GSMP operation across an ATM virtual channel is specified.
- GSMP operation across an Ethernet link is specified.
Other encapsulations are possible, but have not been defined.
Encapsulations are defined in [4].
A label switch is a frame or cell switch that supports connection
oriented switching using the exact match forwarding algorithm
based on labels attached to incoming cells or frames.
A label switch may support multiple label types, however, each
switch port can support only one label type. The label type
supported by a given port is indicated in a port configuration
message. Connections may be established between ports
supporting different label types using the adaptation methods.
There are two forms of labels support; short 28 bit labels
which are sufficient for many purposes and TLV labels which are
defined for labels that do not fit in 28 bits. Examples of the
label types that can use the short form include ATM, Frame
Relay, and MPLS Generic Labels. Examples of labels which are
defined to use the TLV form include DS1, DS3, E1, E3 and MPLS
FECs.
A connection across a switch is formed by connecting an incoming
labelled channel to one or more outgoing labelled channels.
Connections are generally referenced by the input port on which
they arrive and the label values of their incoming labelled
channel. In some messages connections are referenced by the
output port.
GSMP supports point-to-point and point-to-multipoint connections.
A multipoint-to-point connection is specified by establishing
multiple point-to-point connections each of which specifies the
same output label. A multipoint-to-multipoint connection is
specified by establishing multiple point-to-multipoint
connections each of which specifies a different input label
with the same output labels.
In general a connection is established with a certain quality of
service (QoS). This version of GSMP includes a default QoS
Configuration and additionally allows the negotiation of
alternative, optional QoS configurations. The default QoS
Configuration includes three QoS Models: a default service
model, a simple priority model and a QoS profile model. This
version of GSMP also supports the reservation of resources when
the labels are not yet known. This ability can be used in
support of MPLS.
GSMP contains an adjacency protocol. The adjacency protocol is
used to synchronise state across the link, to negotiate which
version of the GSMP protocol to use, to discover the identity
of the entity at the other end of a link, and to detect when it
changes.
3.1 Switch Partitioning
In this version of GSMP switch partitioning is static and occurs
prior to running GSMP. The partitions of a physical switch are
isolated from each other by the implementation and the controller
assumes that the resources allocated to a partition are at all
times available to that partition and only to that partition. A
partition appears to its controller as a physical label switch.
The resources allocated to a partition appear to the controller as
if they were the actual physical resources of a physical switch.
For example if the bandwidth of a port is divided among several
partitions, each partition would appear to the controller to have
its own independent port with its fixed set or resources.
GSMP controls a partitioned switch through the use of a partition
identifier that is carried in every GSMP message. Each partition
has a one-to-one control relationship with its own logical
controller entity (which in the remainder of the document is
referred to simply as a controller) and GSMP independently
maintains adjacency between each controller-partition pair.
3.2 Switch and controller interactions
Multiple switches may be controlled by a single controller using
multiple instantiations of the protocol over separate control
connections.
Alternatively, multiple controllers can control a single switch.
Each controller would establish a control connection to the switch
using the adjacency protocol. The adjacency mechanism maintains a
state table indicating the control connections that are being
maintained by the same partition. The switch provides information
to the controller group about the number and identity of the
attached controllers. It does nothing, however, to co-ordinate
the activities of the controllers, and will execute all commands
as they are received. It is the controller group responsibility
to co-ordinate its use of the switch. This mechanism is most
commonly used for controller redundancy and load sharing.
Definition of the mechanism by which controllers use to co-
ordinate their control is not within GSMP's scope.
3.3 Service support
All GSMP switches must support the default QoS Configuration. A
GSMP switch may additionally support one or more alternative QoS
Configurations. GSMP includes a negotiation mechanism that allows
a controller to select from the QoS configurations that a switch
supports.
The default QoS Configuration includes three models:
The Service Model is based on service definitions found
external to GSMP such as in CR-LDP, Integrated Services or
ATM Service Categories. Each connection is assigned a
specific service that defines the handling of the
connection by the switch. Additionally, traffic parameters
and traffic controls may be assigned to the connection
depending on the assigned service.
In the Simple Abstract Model a connection is assigned a
priority when it is established. It may be assumed that for
connections that share the same output port, an cell or
frame on a connection with a higher priority is much more
likely to exit the switch before a cell or frame on a
connection with a lower priority if they are both in the
switch at the same time.
The QoS Profile Model provides a simple mechanism that allows
QoS semantics defined externally to GSMP to be assigned to
connections. Each profile is an opaque indicator that has
been predefined in the controller and in the switch.
4. Summary of Message Set
The following table gives a summary of the messages defined in
this version of the specification. It also makes a recommendation
of the minimal set of messages that should be supported in an MPLS
environment. These messages will be labelled as "Required",
though the service provided by the other messages are essential
for the operation of carrier quality controller/ switch
operations. GSMPv1.1 or GSMPv2 commands that are no longer
support are marked as "Obsolete" and should no longer be used.
4.1 Messages Table
Message Name Message Number Status
Connection Management Messages
Add Branch .......................16 Required
ATM Specific - VPC............26
Delete Tree.......................18
Verify Tree.......................19 Obsoleted
Delete All Input..................20
Delete All Output.................21
Delete Branches...................17 Required
Move Output Branch............... 22
ATM Specific - VPC............27
Move Input Branch.................23
ATM Specific - VPC............28
Port Management Messages
Port Management...................32 Required
Label Range.......................33
State and Statistics Messages
Connection Activity...............48
Port Statistics...................49 Required
Connection Statistics.............50
QoS Class Statistics..............51 Reserved
Report Connection State...........52
Configuration Messages
Switch Configuration..............64 Required
Port Configuration................65 Required
All Ports Configuration...........66 Required
Service Configuration.............67
Reservation Messages
Reservation Request.............. 70 Required
Delete Reservation................71 Required
Delete All Reservations...........72
Event Messages
Port Up...........................80
Port Down.........................81
Invalid Label.....................82
New Port..........................83
Dead Port.........................84
Abstract and Resource Model Extension Messages
Reserved.Message Range.............200-249
Adjacency Protocol....................10 Required RFC 3294
5. Security Considerations Title: General Switch Management Protocol (GSMP)
Applicability
Author(s): A. Doria, K. Sundell
Status: Informational
Date: June 2002
Mailbox: avri@acm.org,
sundell@nortelnetworks.com
Pages: 9
Characters: 18294
Updates/Obsoletes/SeeAlso: None
The security of GSMP's TCP/IP control channel has been addressed I-D Tag: draft-ietf-gsmp-applicability-02.txt
in [4]. Any potential remaining security considerations are not
addressed in the current revision of this draft.
References URL: ftp://ftp.rfc-editor.org/in-notes/rfc3294.txt
[1] [GSMP-MIB] Sjostrand, H., "Definitions of Managed Objects This memo provides an overview of the GSMP (General Switch Management
for the General Switch Management Protocol Protocol) and includes information relating to its deployment
(GSMP),"Internet-Draft draft-ietf-gsmp-mib- in a IP network in an MPLS environment. It does not discuss
02", July 2000. work in progress deployment in an ATM (Asynchronous Transfer Mode) network or in a raw
ethernet configuration.
[2] [GSMPv1.1] Newman, P, Edwards, W., Hinden, R., Hoffman, E. This document is a product of the General Switch Management Protocol
Ching Liaw, F., Lyon, T. and Minshall, G., Working Group of the IETF.
"Ipsilon's General Switch Management Protocol
Specification," Version 1.1, RFC 1987, August
1996.
[3] [GSMPv2] Newman, P, Edwards, W., Hinden, R., Hoffman, This memo provides information for the Internet community. It does
E., Ching Liaw, F., Lyon, T. and Minshall, G., not specify an Internet standard of any kind. Distribution of this
"Ipsilon's General Switch Management Protocol memo is unlimited.
Specification," Version 2.0, RFC 2397, March
1998.
[4] [GSMP-ENCAPS] T. Worster, "GSMP Packet Encapsulations for This announcement is sent to the IETF list and the RFC-DIST list.
ATM, Ethernet and TCP," Internet-Draft draft- Requests to be added to or deleted from the IETF distribution list
ietf-gsmp-encaps-02, July 2000. work in should be sent to IETF-REQUEST@IETF.ORG. Requests to be
progress added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
[5] [GSMP] Doria, A, Sundell, K, Hellstrand, F, Worster, Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
T, "General switch Management Protocol V3," an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
Internet Draft draft-ietf-gsmp-06.txt, July help: ways_to_get_rfcs. For example:
2000. work in progress
Authors' Addresses To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
Avri Doria help: ways_to_get_rfcs
Nortel Networks
600 Technology Park Drive
Billerica, MA
Phone: +1 401 663 5024
avri@nortelnetworks.com
Kenneth Sundell Requests for special distribution should be addressed to either the
Nortel Networks AB author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
S:t Eriksgatan 115 A specifically noted otherwise on the RFC itself, all RFCs are for
P.O. Box 6701 unlimited distribution.echo
SE-113 85 Stockholm Sweden Submissions for Requests for Comments should be sent to
ksundell@nortelnetworks.com RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
Authors, for further information.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/