One document matched: draft-cha-gsmp-management-01.txt
Differences from draft-cha-gsmp-management-00.txt
GSMP Working Group
YoungWook Cha
TaeHyun Kwon
Internet Draft ANU
Document: draft-cha-gsmp-management-01.txt MinHo Kang
JunKyun Choi
ICU
TaeMan Han
YouHyeon Jeong
ETRI
Expires: May 2003 November 2002
Network Management for GSMP Interface
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 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
General switch management protocol (GSMP) is an open interface
between a label switch and a controller, and it provides connection,
configuration, event, performance management and synchronization. The
managed objects of RFC 3295 are only defined to configure, monitor
and maintain the protocol entity. Traditionally, network management
services are classified into five categories: those are configuration,
performance, fault, accounting, and security management. These
services are provided by the network management functions, which can
be located either in the controller or in the label switch. In the
GSMP interface, there are no managed objects for the network
management services and the location of network management functions
is not clearly defined. We discussed the complexity of switch
implementation and the efficiency of resource usage according to the
location of network management functions.
Cha, et al. Expires - May 2003 [Page 1]
draft-cha-gsmp-management-01.txt November 2002
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Table of Contents
1. Introduction..................................................3
2. Location of Network Management................................3
2.1 Network Management Functions in the Switch................4
2.2 Network Management Functions in the Controller............5
3. Network Management Services in GSMP Interface.................7
3.1 Connection Management.....................................8
3.2 Configuration Management.................................11
3.3 Performance Management...................................12
3.4 Event Management.........................................12
4. Security Considerations......................................13
References......................................................13
Acknowledgments.................................................14
Author's Addresses..............................................14
Cha, et al. Expires - May 2003 [Page 2]
draft-cha-gsmp-management-01.txt November 2002
1. Introduction
General switch management protocol (GSMP) provides an open interface
that can be used to separate the data forwarder from the routing and
other control plane protocols. GSMP protocol is asymmetric, the
controller being the master and the switch being the slave. GSMP
allows a controller to establish and release connections across the
label switch; manage switch ports; request configuration information;
request and delete reservation of switch resources; and request
statistics. It also allows the label switch to inform the controller
of asynchronous events such as a link going down. GSMP contains an
adjacency protocol, which is used to synchronize states across the
link [1].
In the beginning, GSMP was intended only for use with ATM switches.
GSMP has been extended to support multiple label types those are ATM,
frame relay, multiprotocol label switching (MPLS) generic labels. In
the MPLS system, it is possible to run the routing protocols and
label distribution protocols on a controller while passing data
across a label switch. GSMP provides the switch resource management
mechanism needed in such a scenario [2]. GSMP is well suited for
network architectures that employ label swapping in the forwarding
plane. This property makes GSMP a good fit for generalized labels as
defined by generalized MPLS. GSMP extensions have been progressing to
support optical switching [3].
2. Location of Network Management
The document of GSMP-MIB, RFC 3295 defines managed objects for the
GSMP protocol [4]. It is just a protocol MIB to configure, monitor
and maintain the protocol entity. Traditionally, network management
services are classified into five categories: those are configuration,
performance, fault, accounting, and security management. These
services are provided by the network management functions, which can
be located either in the controller or in the label switch. In the
GSMP interface, the MIB for the network management service is not
defined yet, and the location of network management functions is not
reviewed in various factors. The companion draft document presents
managed objects to support network management services in the GSMP
interface [5].
Using the connection management service, we analyzed the complexity
of switch implementation and the efficiency of resource usage
according to the location of network management functions.
Connections are usually classified into two types: a dynamic
connection and a provisioned connection. A dynamic connection is
Cha, et al. Expires - May 2003 [Page 3]
draft-cha-gsmp-management-01.txt November 2002
controlled by the signaling protocol in the controller, and a
provisioned connection is managed by the network management system.
2.1 Network Management Functions in the Switch
In the GSMP interface, the controller decides the establishment of a
dynamic connection, and the switch merely responses the commands from
the controller. For provisioning a connection in the GSMP interface,
network management functions can be located either in the controller
or in the label switch.
Controller
+------------------------------------+
| +------------------------------+ |
| | Coordinator | |
| +----^-----------^-------------+ |
| | | +----------+ |
| | +->| CR-LDP, | |
| | | RSVP-TE | |
| v +----------+__|
| +------------------------------+ |
| | GSMP - Master | |
| +------------------------------+ |
+------------------------------------+
|
-+-
Label Switch |
+------------------------------------+
| +------------------------------+ |
| | GSMP - Slave | |
| +----------------^-------------+ |
+---------+ | | +----------+ | +----------+ |
| NMS |--+-|--| SNMP | +->| System | |
+---------+ | | | Agent |<------>|Management| |
| +----------+ +-----^----+ |
| | |
| +-------------------------v----+ |
| | ------------ ------------- | |
| | X | |
| | ------------ ------------- | |
| +------------------------------+ |
+------------------------------------+
Figure 1: Network Management Functions in the Switch
Figure 1 shows that the switch has SNMP agent functions for network
management services. If the switch manages the provisioned connection
Cha, et al. Expires - May 2003 [Page 4]
draft-cha-gsmp-management-01.txt November 2002
in cooperation with the network management system (NMS), the
controller cannot maintain the exact status about switch resources.
The potential problem is that the controller can reassign a dynamic
connection switch resources allocated to the provisioned connection.
The one scheme for overcoming the reallocation problem is that the
switch resources are divided into two groups: one group is for
dynamic connections and the other group is for provisioned
connections. According to the connection types, the switch resources
are managed by the controller or label switch. The separation of
switch resources will resolve the reallocation problem, but it will
cause the usage of resources to be inefficient. That is, a connection
cannot be established because of its resource shortage, even though
the other group is plenty.
If the SNMP agent is located in the switch, the switch should
implement the SNMP interface as well as the GSMP interface. The
implementation of these interfaces will cause the switch to be
complex.
2.2 Network Management Functions in the Controller
If we consider the SNMP agent is located in the controller shown in
Fig. 2, the label switch can be lightly implemented with the GSMP
slave and basic system management functions. The NMS commands the
controller to manage a provisioned connection, then the controller
issues GSMP messages to the label switch. In this model, the
controller can manage all switch resources for the dynamic and
provisioned connections, so inefficient resource usage and resource
reallocation problem of Fig. 1 can be eliminated.
Especially, this model is effective approach in the environment,
where a single controller manages multiple switches shown in Fig. 3.
It is not necessary for each label switch to implement SNMP agent
function in the centralized server model. SNMP agent is only located in the controller. In this
configuration, the manager can identify each switch using the SNMP
community values, which are uniquely allocated for each switch. This
mitigation of switch implementation burden coincides with the open
interface concept.
Cha, et al. Expires - May 2003 [Page 5]
draft-cha-gsmp-management-01.txt November 2002
Controller
+------------------------------------+
| +------------------------------+ |
| | Coordinator | |
| +------------------------------+ |
| ^ ^ ^ |
| +-------+ | +--------+ |
+---------+ | | +---------+ | | | +----------+ |
| NMS |--+-|--| SNMP |<-+ | +->| CR-LDP | |
+---------+ | | | Agent | | | RSVP-TE | |
| +---------+ v +----------+ |
| +------------------------------+ |
| | GSMP - Master | |
| +------------------------------+ |
+------------------------------------+
|
-+-
Label Switch |
+------------------------------------+
| +------------------------------+ |
| | GSMP - Slave | |
| | System Management | |
| +------------------------------+ |
| | ^ |
| v | |
| +------------------------------+ |
| | ------------ ------------- | |
| | Switch X Fabric | |
| | ------------ ------------- | |
| +------------------------------+ |
+------------------------------------+
Figure 2: Network Management Functions in the Controller
Cha, et al. Expires - May 2003 [Page 6]
draft-cha-gsmp-management-01.txt November 2002
+---------+
| NMS |
+---------+
^
|
SNMP -+-
| *Community - A,B,...
v
+-------------+
| +---------+ |
| | Agent | |
| +---------+ |
| | Master | |
| +---------+ |
+-------------+
| | |
+-----------+ | +-------------+
| | |
-+- -+- GSMP -+-
| | |
+----------+ +----------+ +----------+
|+--------+| |+--------+| |+--------+|
|| Slave || || Slave || ... || Slave ||
|+--------+| |+--------+| |+--------+|
| X | | X | | X |
+----------+ +----------+ +----------+
Switch-A Switch-B ... Switch-n
Figure 3: Network Management Model in Centralized Server
3. Network Management Services in GSMP Interface
If the SNMP agent is located in the controller, it is required that
network management functions be mapped with GSMP functions. There are
two approaches to enable the mapping scenarios between the SNMP agent
and the GSMP master. The one approach is using the existing managed
objects, which are defined in ATM-MIB [6] or MPLS-MIB [7-9]. The
other approach is to define new managed objects, which will reflect
the information elements of each GSMP message. The companion draft
document defines GSMP service MIB, which includes managed objects
supporting network management services in the GSMP interface [5]. If
we use the GSMP service MIB, then mapping functions will be more
simple than using the existing MIB. These simple mapping functions
Cha, et al. Expires - May 2003 [Page 7]
draft-cha-gsmp-management-01.txt November 2002
can be accomplished because the GSMP service MIB is defined to
accommodate the information elements of GSMP messages. Figure 4 shows
the mapping scenarios for each GSMP message.
+------------------------+--------------------------+
| GSMP messages | MIB |
+------------------------+--------------------------+
| | Existing MPLS/ATM-MIB or |
| Connection messages | |
| | New MIB |
+------------------------+--------------------------+
| | Existing MPLS/ATM-MIB or |
| Statistics messages | |
| | New MIB |
+------------------------+--------------------------+
| Configuration messages | New MIB |
+------------------------+--------------------------+
| Event messages | Notifications in GSMP MIB|
+------------------------+--------------------------+
Figure 4: Mapping Scenarios
GSMP connection and statistics messages can be mapped with the
existing MIBs(e.g., MPLS- MIB or ATM-MIB) or new GSMP service MIB.
GSMP configuration messages permit the controller to discover the
capabilities of the switch. In the existing MIBs, there are no
managed objects or tables, which are mapped with the GSMP
configuration messages. To support the mapping procedures between
GSMP configuration messages and network management functions, it is
required to define new configuration tables. GSMP event messages can
be mapped with the notifications defined in the GSMP MIB [4].
3.1 Connection Management
A connection is modeled as a cross-connect consisting of one or more
incoming segments (in-segments) and/or one or more outgoing segments
(out-segments) at a switch. The association or interconnection of the
in-segments and out-segments is accomplished by using a cross-connect
table. To support connection management services, the existing
MIBs(e.g., MPLS-MIB, ATM-MIB) and the GSMP service MIB define five
main tables: interface configuration, traffic parameter, in-segment,
out-segment, and cross-connect tables [5][7]. These tables in the GSMP
service MIB can be more exactly mapped with the GSMP messages than
those tables in the existing MIBs.
Cha, et al. Expires - May 2003 [Page 8]
draft-cha-gsmp-management-01.txt November 2002
Figure 5 shows the relationship among these five tables. A row in the
cross-connect table consists of one cross-connect entry that is
indexed by the cross-connect index, interface index of the
incoming segment, incoming label, and out-segment index.
Interface Table
+-------+---+
|IfIndex| |
+-------+---+
+-----------------------+-- X | |
| +-------+---+
| | Y --+---+-------------------------+
| +-------+---+ |
| |
| TrafficPram Table |
| +-----------------+ |
| +-+-+--+--+--+--+ + |
| | | | | | +---+ |
| +---+--+--+--+--+ | |
| | | |
| InSegment Table v v OutSegment Table |
| +-------+----+----------+ +-----------+-----+--------+ |
+->|InSIfId|InSL|InSTrpaPtr| |OutSTrpaPtr|OutSL|OutSIfId|<---+
+-----------------------+ +-----------+-----+--------+
| | | |
+------+-------------+ +------+ |
+-----+ | | |
v v v v
+---------+---------+------+----------+----------+
| XCIndex | InSIfId | InSL | OutSIfId | OutSIfId |
+---------+---------+------+----------+----------+
XC Table
If : Interface, L : Label, XC : cross-connect, Id : Index,
TrpaPtr : Traffic Parameter Row Pointer, S : Segment
Figure 5: Cross-Connect Links
GSMP connection messages are used by the controller to establish,
delete and modify connections across the switch. Figure 6 shows the
mapping procedures for a provisioned connection, which is established
and deleted by the manager.
Cha, et al. Expires - May 2003 [Page 9]
draft-cha-gsmp-management-01.txt November 2002
Manager Controller Switch
| | |
|Set(TrafficParaEntryForInSegment) | |
|---------------------------------->| |
|GetResponse | |
|<----------------------------------| |
|Set(TrafficParaEntryForOutSegment) | |
|---------------------------------->| |
|GetResponse | |
|<----------------------------------| |
|Set(InSegmentEntry) | |
|---------------------------------->| |
|GetResponse | |
|<----------------------------------| |
|Set(OutSegmentEntry) | |
|---------------------------------->| |
|GetResponse | |
|<----------------------------------| |
|Set(XCEntry) | |
|---------------------------------->| Add Branch |
| |-------------->|
| | Ack |
|GetResponse |<--------------|
|<----------------------------------| |
|Set(XCRowStatus=destroy) | |
|---------------------------------->|Delete Tree |
| |-------------->|
| | Ack |
|GetResponse |<--------------|
|<----------------------------------| |
| | |
Figure 6: Mapping Procedures for a Provisioned Connection
To establish a provisioned connection, the manager first sets segment
entries and their associated traffic parameter entries. If the
segments are successfully created, the manager requests the
controller to create a cross-connect entry. If the row status of the
cross-connect entry is 'CreateAndGo', then the controller commands
the label switch to establish the provisioned connection using the
GSMP Add Branch message. If the row status of the cross-connect entry
is 'CreateAndWait', then the controller commands the label switch to
reserve the provisioned connection using the GSMP Reservation message.
If the switch responds with the positive acknowledgement, the
controller completes establishment of the provisioned connection by
returning the SNMP Get Response message to the manager.
Cha, et al. Expires - May 2003 [Page 10]
draft-cha-gsmp-management-01.txt November 2002
The manager deletes the provisioned connection by setting the row
status of the cross-connect entry as destroy. Then, the controller
requests the switch to delete the provisioned connection using the
GSMP Delete Tree message.
3.2 Configuration Management
GSMP configuration messages permit the controller to discover the
capabilities of the switch. Three configuration request messages have
been defined in the GSMP: Switch, Port, and Service messages [1]. In
the existing MIBs, there are no managed objects or tables, which are
mapped with the GSMP configuration messages. To support the mapping
procedures between GSMP configuration management and network
management, it is required to define configuration tables.
Figure 7 shows new configuration tables, which are defined in the
GSMP service MIB [5]. These tables are mapped with the GSMP
configuration messages. The columnar objects of these table entries
are based on the information elements of the GSMP configuration
messages.
+-----------------------+------------------------+
| GSMP Message | Configuration Table |
+-----------------------+------------------------+
| Switch Configuration | gsmpSwitchConfTable |
+-----------------------+------------------------+
| Port Configuration | gsmpInterfaceConfTable |
| | gsmpPortServiceMapTable|
+-----------------------+------------------------+
| Service Configuration | gsmpServiceTable |
+-----------------------+------------------------+
Figure 7: Configuration Tables for Network Management
Figure 8 shows the relationship between interface and service
configuration tables. The entry of gsmpInterfaceConfTable represents
the configuration information of a single switch port. The
gsmpServiceTable represents the list of services and their associated
parameters, which are supported by the switch. The entry of
gsmpPortServiceMapTable represents the service lists, which are
supported by the specific port.
Cha, et al. Expires - May 2003 [Page 11]
draft-cha-gsmp-management-01.txt November 2002
InterfaceConfIndex
+-+-----+ One or More +----------+ +---+----+----+
|x| ----+---------+--->|x|SID|CSID|----->|SID|CSID| |
+-+-----+ | +-+---+----+ +---+----+----+
|Y| + +--->|X|SID|CSID| |SID|CSID| |
+-+-----+ +-+---+----+ +---+----+----+
|Z| | |Y|SID|CSID+ +-->+SID|CSID| +
+-+-----+ +-+---+----+ | +---+----+----+
InterfaceConfTable |Z|SID|CSID+--+ |SID|CSID| +
+-+---+----+ +---+----+----+
|Z|SID|CSID+ ServiceTable
+-+---+----+
PortServiceMapTable
SID : Service ID, CSID : Capability Set ID
Figure 8: Relationship between Interface and Service Configuration
Tables
3.3 Performance Management
The statistics messages of GSMP permit the controller to request the
values of various hardware counters associated with the connections,
input and output ports [1]. The MPLS segment performance tables
contain the objects necessary to measure the performance of segments.
The MPLS interface performance table has objects to measure MPLS
performance on a per-interface basis [7]. The counter information
elements of the Connection Statistics message can be mapped with the
columnar objects of the existing segment performance table entry. It
is possible to map each entry of the existing interface performance
table with the GSMP Port Statistics message.
However, the columnar objects of these table entries cannot be
exactly mapped with the GSMP statistics messages. In the GSMP service
MIB [5], there are two performance tables, which are
gsmpInterfacePerfTable and gsmpLabelPerfTable. These tables can be
fully mapped with the GSMP statistics messages.
3.4 Event Management
GSMP allows the switch to inform the controller of asynchronous
events. The events defined in GSMP are Port Up, Port Down, Invalid
Label, New Port, Dead Port and Adjacency Update [1]. If GSMP event is
received from the switch, the controller will inform the manager of
Cha, et al. Expires - May 2003 [Page 12]
draft-cha-gsmp-management-01.txt November 2002
the received event using the notifications. GSMP-MIB [4] defines
notifications, which can be mapped with the GSMP events. Figure 9
shows GSMP events and their related notifications.
+-------------------+--------------------------+
| Event | Notification |
+-------------------+--------------------------+
| Port Up | gsmpPortUpEvent |
+-------------------+--------------------------+
| Port Down | gsmpPortDownEvent |
+-------------------+--------------------------+
| Invalid Label | gsmpInvalidLabelEvent |
+-------------------+--------------------------+
| New Port | gsmpNewPortEvent |
+-------------------+--------------------------+
| Dead Port | gsmpDeadPortEvent |
+-------------------+--------------------------+
| Adjacency Update | gsmpAdjacencyUpdateEvent |
+-------------------+--------------------------+
Figure 9: GSMP Events and Notifications
4. Security Considerations
This document does not have any security concerns. The security
requirements using this document are described in the referenced
documents.
References
1 A. Doria, et al., "General Switch Management Protocol," RFC 3292,
June 2002.
2 A. Doria, et al., "General Switch Management Protocol
Applicability," RFC 3294, June 2002.
3 Georg Kullgren et al., "Requirements for adding Optical Switch
Support to GSMP," Internet draft, <draft-ietf-gsmp-reqs-03.txt>,
Sep. 2002.
4 H. Sjostrand et al., "Definitions of Managed Objects for the
General Switch Management Protocol," RFC 3295, June 2002.
Cha, et al. Expires - May 2003 [Page 13]
draft-cha-gsmp-management-01.txt November 2002
5 YoungWork Cha et al., "Definitions of Managed Objects for Network
Management Services in General Switch Management Protocol (GSMP)
Interface," Internet draft, <draft-cha-gsmp-service-mib-00.txt>,
November 2002.
6 K. Tesink et al., "Definitions of Managed Objects for ATM
Management," RFC 2515, Feb. 1999.
7 Cheenu Srinivasan et al., "MPLS Label Switch Router Management
Information Base Using SMIv2," Internet draft, <draft-ietf-mpls-
lsr-mib-09.txt>, Oct. 2002.
8 Thomas D. Nadeau et al., "Multiprotocol Label Switching (MPLS)
FEC-ToNHLFE (FTN) Management Information Base Using SMIv2,"
Internet draft, <draft-ietf-mpls-ftn-mib-04.txt>, Jan. 2002.
9 Cheenu Srinivasan et al., "MPLS Traffic Engineering Management
Information Base Using SMIv2," Internet draft, <draft-ietf-mpls-
te-mib-08.txt>, Jan. 2002.
Acknowledgments
This work was supported in part by the Korean Science and Engineering
Foundation (KOSEF) through OIRC project.
Author's Addresses
YoungWook Cha
Andong National University (ANU)
388 Song-chon Dong, Andong, Kyungsangbuk-do
Korea 760-749
Phone: +82-54-820-5714
Email: ywcha@andong.ac.kr
TaeHyun Kwon
Andong National University (ANU)
388 Song-chon Dong, Andong, Kyungsangbuk-do
Korea 760-749
Phone: +82-54-820-6039
Email: freeman@comeng.andong.ac.kr
KyungMann Lee
Andong National University (ANU)
388 Song-chon Dong, Andong, Kyungsangbuk-do
Korea 760-749
Phone: +82-54-820-6039
Email: kmlee@anu.ac.kr
JunKyun Choi
Information and Communications University (ICU)
58-4 Hwa Ahm Dong, Yusong, Taejon
Cha, et. Al. Expires - May 2003 [Page 14]
draft-cha-gsmp-management-01.txt November 2002
Korea 305-732
Phone: +82-42-866-6122
Email: jkchoi@icu.ac.kr
MinHo kang
Information and Communications University (ICU)
58-4 Hwa Ahm Dong, Yusong, Taejon
Korea 305-732
Phone: +82-42-866-6136
Email: mhkang@icu.ac.kr
TaeMan Han
Electronics and Telecommunications Research Institute(ETRI)
161 Gajeong-dong, Yusong, Taejon
Korea 305-350
Phone: +82-42-860-5245
Email: tmhan@etri.re.kr
YouHyeon Jeong
Electronics and Telecommunications Research Institute(ETRI)
161 Gajeong-dong, Yusong, Taejon
Korea 305-350
Phone: +82-42-860-5245
Email: yhjeong@etri.re.kr
Cha, et. Al. Expires - May 2003 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 20:19:49 |