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, , 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, , 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, , Oct. 2002. 8 Thomas D. Nadeau et al., "Multiprotocol Label Switching (MPLS) FEC-ToNHLFE (FTN) Management Information Base Using SMIv2," Internet draft, , Jan. 2002. 9 Cheenu Srinivasan et al., "MPLS Traffic Engineering Management Information Base Using SMIv2," Internet draft, , 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]