GSMP Working Group YoungWook Cha TaeHyun Kwon Internet Draft ANU Document: draft-cha-gsmp-management-00.txt JunKyun Choi MinHo Kang ICU YoungHwa Kim ETRI Expires: December 2002 June 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 protocol between a label switch and a controller, and it provides connection, configuration, event, performance management and synchronization. In the GSMP interface, network management functions can be located either in the controller or in the label switch. We discussed the implementation complexity of a label switch and the efficiency of resource usage according to the location of network management functions. 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. Cha, et al. Expires - December 2002 [Page 1] draft-cha-gsmp-management-00.txt June 2002 Table of Contents 1. Introduction..................................................3 2. Location of Network Management................................3 2.1 Network Management Functions in the Switch...............3 2.2 Network Management Functions in the Controller...........4 3. Mapping Scenarios for MPLS Network Management.................6 3.1 MPLS Network Management..................................6 3.2 Mapping Scenarios........................................7 3.2.1 Connection Management..................................7 3.2.2 Configuration Management...............................8 3.2.3 Performance Management.................................9 3.2.4 Event Management.......................................9 4. Security Considerations......................................10 References......................................................10 Acknowledgments.................................................11 Author's Addresses..............................................11 Cha, et al. Expires - December 2002 [Page 2] draft-cha-gsmp-management-00.txt June 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]. There are two kinds of connections: a dynamic connection and a provisioned connection. A dynamic connection is controlled by the signaling protocol in the controller, and a provisioned connection is managed by the network management system. For provisioning a connection in the GSMP interface, network management functions can be located either in the controller or in the label switch. 2. Location of Network Management In this section, we discussed the complexity of a label switch and the efficiency of resource usage according to the location of network management functions. 2.1 Network Management Functions in the Switch In the GSMP interface, the controller decides the establishment of a connection by a connection admission control, and the switch merely responses the commands from the controller. If the switch has agent functions for network management, and it manages the provisioned connection in cooperation with the manager, the controller will not Cha, et al. Expires - December 2002 [Page 3] draft-cha-gsmp-management-00.txt June 2002 aware of the status about all switch resources. For a connection admission control, it is required to keep the switch resource status in the controller. This can be accomplished if the switch informs the controller of its resource status, whenever a provisioned connection is established or deleted by the manager. The potential problem is that the controller can reassign switch resources allocated to the provisioned connection to a dynamic connection. This reallocation problem will be originated from the delayed notification of the resource status changed by the provisioned connection. The one scheme for overcoming this 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. 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 can be established because of its resource shortage, even though the other part of resources has plenty in reserve. 2.2 Network Management Functions in the Controller If the simple network management (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 complexity of the switch to be increased. If we consider the SNMP agent is located in the controller shown in Fig. 1, the label switch can be easily implemented with the GSMP slave and basic system management functions. In this model, the manager commands the controller to manage a provisioned connection, then the controller issues GSMP messages to the label switch. Cha, et al. Expires - December 2002 [Page 4] draft-cha-gsmp-management-00.txt June 2002 Controller +------------------------------------+ | +------------------------------+ | | | Coordinator | | | +------------------------------+ | | ^ ^ ^ | | +-------+ | +--------+ | +---------+ | | +---------+ | | | +----------+ | | Manager |--+-|--| SNMP |<-+ | +->| CR-LDP | | +---------+ | | | Agent | | | RSVP-TE | | | +---------+ v +----------+__| | +------------------------------+ | | | GSMP - Master | | | +------------------------------+ | +------------------------------------+ | -+- Label Switch | +------------------------------------+ | +------------------------------+ | | | GSMP - Slave | | | +------------------------------+ | | | System Management | | | +------------------------------+ | | | ^ | | v | | | +------------------------------+ | | | ------------ ------------- | | | | Switch X Fabric | | | | ------------ ------------- | | | +------------------------------+ | +------------------------------------+ Figure 1: Management Model in the GSMP Interface When the controller manages multiple switches, SNMP agent is not implemented in the all switches, but in the controller. This mitigation of switch implementation burden coincides with the open interface concept [4]. In addition, the controller can manage all switch resources for the dynamic and provisioned connections, and inefficient usage of switch resources by dividing them two groups can be eliminated. If the SNMP agent is located in the controller as shown in Fig. 1, it is required that network management functions be mapped with GSMP functions. Cha, et al. Expires - December 2002 [Page 5] draft-cha-gsmp-management-00.txt June 2002 3. Mapping Scenarios for MPLS Network Management In this section, we will briefly introduce the MPLS network management, and present example mapping scenarios between MPLS network management functions and GSMP functions. These mapping scenarios will be applicable to the generalized MPLS network management. 3.1 MPLS Network Management Integration of IP routing and layer 2 switching in MPLS, enables fast forwarding, traffic engineering and virtual private network services. A router capable of MPLS is a label switching router (LSR) and a set of LSRs traversed by a packet is called a label-switched path (LSP) [5]. Figure 2 shows management information bases (MIBs) for MPLS network management, which are MPLS-FTN (FEC To Next hop forwarding label entry), MPLS-LSR and MPLS-TE (Traffic Engineering) MIBs [6-8]. +--------------+ +-| MPLS-TE MIB | +--------------+ | | MPLS-LSR MIB | | MPLS-FTN MIB | | +--------------+ +--------------+ | | +---------------+----------------------+ | | | | +--|---|---------------|----------------------|--+ | v v v v | +----------+ +----------+ +----------+ --> | Ingress |---------| Core LSR |----------| Egress | --> | LSR |---------| |----------| LSR | +----------+ +----------+ +----------+ | | +------------------------------------------------+ Figure 2: MIBs for MPLS Network Management On the ingress of MPLS network, packets entering the MPLS domain are assigned to a forwarding equivalence class (FEC). Those packets belonging to a FEC are associated with a next hop label forwarding entry. MPLS FTN MIB defines how the LSR will impose MPLS labels onto incoming flows [6]. The MPLS-TE MIB is designed to support point-to-point unidirectional tunnels with appropriate configuration parameters. If a tunnel configured, then a LSP will be created using the MPLS-LSR MIB [8]. A LSP is modeled as a connection consisting of one or more incoming segments (in-segments) and/or one or more outgoing segments (out- Cha, et al. Expires - December 2002 [Page 6] draft-cha-gsmp-management-00.txt June 2002 segments) at a LSR. The association or interconnection of the in- segments and out-segments is accomplished by using a cross-connect tables. The MPLS-LSR MIB supports four main tables: interface configuration, in-segment, out-segment, and cross-connect. MPLS cross-connect table associates in-segments to out-segments to show the manager how the LSR is currently swapping these labels [7]. 3.2 Mapping Scenarios 3.2.1 Connection Management GSMP connection messages are used by the controller to establish, delete and modify connections across the switch. Figure 3 shows the mapping procedures for a provisioned LSP, which is established and deleted by the manager. 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 Branches| | |-------------->| | | Ack | |GetResponse |<--------------| |<----------------------------------| | | | | Figure 3: Mapping Procedures for a Provisioned Connection Cha, et al. Expires - December 2002 [Page 7] draft-cha-gsmp-management-00.txt June 2002 To establish a provisioned connection, the manager first sets segments and their traffic parameters using the MPLS-LSR MIB. If the segments are successfully created, the manager requests the controller to create a cross-connect entry. The controller commands the label switch to set the provisioned connection using the GSMP Add Branch message. If the switch responds with the positive acknowledgement of Add Branch message, the controller completes establishment of the provisioned connection by returning the SNMP Get Response message to the manager. 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 Branches message. 3.2.2 Configuration Management GSMP configuration messages permit the controller to discover the capabilities of the switch. Three configuration request messages have been defined: Switch, Port, and Service messages [1]. In the MPLS network management, 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 the configuration tables in the MIB. Table 1 shows configuration tables, which are mapped with the GSMP configuration messages. +-----------------------+----------------------+ | GSMP Message | Configuration Table | +-----------------------+----------------------+ | Switch Configuration | GsmpSwitchConfTable | +-----------------------+----------------------+ | Port Configuration | GsmpPortConfTable | +-----------------------+----------------------+ | Service Configuration | GsmpServiceConfTable | +-----------------------+----------------------+ Figure 4: Configuration Tables for Network Management Figure 5 shows the GsmpSwitchConfTable mapped with the Switch Configuration message. The GSMP Switch Configuration message requests the global (non port-specific) configuration for the switch. The columnar objects of this table entry are based on the information elements of the Switch Configuration message. This table is indexed by the switch partition identifier whose value matches that of the Switch Configuration message. Cha, et al. Expires - December 2002 [Page 8] draft-cha-gsmp-management-00.txt June 2002 gsmpSwitchConfTable OBJECT-TYPE SYNTAX SEQUENCE OF GsmpSwitchConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table specifies switch configuration." ::= { gsmprObjects 1 } gsmpSwitchConfEntry OBJECT-TYPE SYNTAX GsmpSwitchConfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This entry specifies the global (not port specific) configuration for the switch partition." INDEX { gsmpSwitchPartitionIndex } ::= { gsmpSwitchConfTable 1 } GsmpSwitchConfEntry::= SEQUENCE { GsmpSwitchPartitionIndex Integer, GsmpSwitchConfMtype1 Integer, GsmpSwitchConfMtype2 Integer, GsmpSwitchConfMtype3 Integer, GsmpSwitchConfMtype4 Integer, GsmpSwitchConfFirmVer Integer, GsmpSwitchConfWindowSize Integer, GsmpSwitchConfSwitchType OCTET STRING, GsmpSwitchConfSwitchName OCTET STRING, GsmpSwitchConfMaxReservation Integer } Figure 5: Switch Configuration Table 3.2.3 Performance Management The MPLS in-segment and out-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 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 counter information elements of the Connection Statistics message are mapped with the columnar objects of segment performance table entry. It is possible to map each entry of the MPLS interface performance table with GSMP Port Statistics message. 3.2.4 Event Management Cha, et al. Expires - December 2002 [Page 9] draft-cha-gsmp-management-00.txt June 2002 The MPLS-LSR MIB includes two Notifications those are cross-connect- up and cross-connect-down. These Notifications are generated when the operational status of cross-connect are about to enter the up or down state from some other [7]. 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 received event using the GSMP Notifications [9]. Figure 6 shows GSMP Notifications, which are mapped with GSMP event messages. +-------------------+--------------------------+ | Event | Notification | +-------------------+--------------------------+ | Port Up | gsmpPortUpEvent | +-------------------+--------------------------+ | Port Down | gsmpPortDownEvent | +-------------------+--------------------------+ | Invalid Label | gsmpInvalidLabelEvent | +-------------------+--------------------------+ | New Port | gsmpNewPortEvent | +-------------------+--------------------------+ | Dead Port | gsmpDeadPortEvent | +-------------------+--------------------------+ | Adjacency Update | gsmpAdjacencyUpdateEvent | +-------------------+--------------------------+ Figure 6: Notifications and GSMP events 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," Internet draft, , May 2001. 2 A. Doria, et al., "General Switch Management Protocol Applicability," Internet draft, , Aug. 2001. Cha, et al. Expires - December 2002 [Page 10] draft-cha-gsmp-management-00.txt June 2002 3 Avri Doria et al., "Requirements for adding Optical Switch Support to GSMP," Internet draft, , July 2001. 4 Nils Bjorkman et al., "The Movement from Monoliths to Componet- Based Network Elements," IEEE Communications Magazine, Jan. 2001. 5 Jeremy Lawrence, "Designing Multiprotocol Label Switching Networks," IEEE Communications Magazine, July 2001. 6 Thomas D. Nadeau et al., "Multiprotocol Label Switching (MPLS) FEC-ToNHLFE (FTN) Management Information Base Using SMIv2," Internet draft, , April 2001. 7 Cheenu Srinivasan et al., "MPLS Label Switch Router Management Information Base Using SMIv2," Internet draft, , Jan. 2001. 8 Cheenu Srinivasan et al., "MPLS Traffic Engineering Management Information Base Using SMIv2," Internet draft, , Aug. 2001. 9 Hans Sjostrand et al., "Definitions of Managed Objects for the General Switch Management Protocol," Internet draft, , Nov. 2001. 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 JunKyun Choi Information and Communications University (ICU) 58-4 Hwa Ahm Dong, Yuseong, Daejeon Korea 305-732 Cha, et al. Expires - December 2002 [Page 11] draft-cha-gsmp-management-00.txt June 2002 Phone: +82-42-866-6122 Email: jkchoi@icu.ac.kr MinHo kang Information and Communications University (ICU) 58-4 Hwa Ahm Dong, Yuseog, Daejeon Korea 305-732 Phone: +82-42-866-6136 Email: mhkang@icu.ac.kr YoungHwa Kim Electronics and Telecommunications Research Institute(ETRI) 161 Gajeong-dong, Yuseong, Daejeon Korea 305-350 Phone: +82-42-860-5819 Email: yhwkim@etri.re.kr Cha, et al. Expires - December 2002 [Page 12]