idnits 2.17.1 draft-ietf-gsmp-applicability-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 155 has weird spacing: '...riority model...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '6' is defined on line 327, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-gsmp-mib-01 ** Downref: Normative reference to an Informational RFC: RFC 1987 (ref. '2') == Outdated reference: A later version (-05) exists of draft-ietf-gsmp-encaps-00 == Outdated reference: A later version (-11) exists of draft-ietf-gsmp-04 == Outdated reference: A later version (-05) exists of draft-ietf-gsmp-encaps-00 -- Duplicate reference: draft-ietf-gsmp-encaps, mentioned in '6', was also mentioned in '4'. Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Avri Doria, Nokia 2 GSMP Working Group Kenneth Sundell, Nortel Networks 3 Standards Track 10 March, 2000 5 General Switch Management Protocol Applicability 7 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as "work 21 in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This memo provides an overview of the GSMP protocol and includes 32 information relating to its deployment in a MPLS environment. 34 1. Overview 36 The General Switch Management Protocol (GSMP) has been available 37 to the IETF community for several years now as informational 38 RFC's. Both V1.1 released in March 1996 as RFC1987 [2], and V2.0 39 released in August 1998 as RFC2297 [3] are available. V1.1 has 40 been implemented by several vendors. 42 In V1.1 and V2 GSMP was intended only for use with ATM switches. 43 During the course of the last year, the GSMP working group has 44 decided to expand the purview of GSMP to the point where it can be 45 used to control a number of different kinds of switch and can thus 46 live up to what its name indicates; a general switch management 47 protocol. To do this, commands and arguments needed to be 48 generalised, with sections added discussing the manner in which 49 the generalised protocol could be applied to specific kinds of 50 switches and port types. In short the protocol has gone through 51 major changes in the last 18 months. 53 GSMP provides an interface which can be used to separate the data 54 forwarder from the routing and other control plane protocols such 55 as LDP. As such it allows service providers to move away from 56 monolithic systems which bundle control plane and data plane into 57 a single tightly coupled system - usually in a single chassis. 58 Separating the control components from the forwarding components 59 and using GSMP for switch management, enables service providers to 60 create multi-service systems composed of various vendors 61 equipment. 63 The IETF GSMP working group was established in the routing area 64 because GSMP was being seen as an optional part of the MPLS 65 solution. In a MPLS system, it is possible to run the routing 66 protocols and label distribution protocols on one system while 67 passing data across a generic switch, e.g. an ATM switch. GSMP 68 provides the management mechanism needed in such a scenario. 70 GSMP has also been selected by the Multiservice Switching 71 Forum(MSF) as its protocol of choice for the Switch Control 72 Interface identified in their architecture. The MSF is an 73 industry forum which establishes their member's requirements and 74 then works with the appropriate standards bodies to foster their 75 goals. In the case of GSMP, the MSF presented the IETF GSMP 76 Working Group with a set of requirements for GSMP. The working 77 group has made a determined effort to comply with those 78 requirements. 80 2. GSMP V3 Document Set 82 The current version of GSMP is documented in 3 documents: 84 - General Switch Management protocol V3 [5] 86 - GSMP Packet Encapsulations for ATM, Ethernet and TCP 88 - Definitions of Managed Objects for the General Switch 89 Management Protocol [1] 91 3. Description of protocol 93 The General Switch Management Protocol V3 (GSMPv3) [5], is a 94 general purpose protocol to control a label switch. GSMP allows 95 a controller to establish and release connections across the 96 switch; add and delete leaves on a multicast connection; 97 reserve resources; manage switch ports; request configuration 98 information; and request statistics. It also allows the switch 99 to inform the controller of asynchronous events such as a link 100 going down. The GSMP protocol is asymmetric, the controller 101 being the master and the switch being the slave. 103 A physical switch can be partitioned in many virtual switches. 104 GSMP does not provide support for defining switch partitions. 105 GSMP treats a virtual switch as if it were a physical switch. 107 GSMP may be transported in three ways: 109 - GSMP may run across an ATM link connecting the controller 110 to the switch, on a control connection (virtual channel) 111 established at initialisation. 113 - GSMP operation across an Ethernet link is specified. 115 - GSMP operation across an IP network is specified. 117 Other encapsulation are possible, but have not been defined. 118 Encapsulation are defined in a separate standards track document. 120 A label switch is a frame or cell switch that supports connection 121 oriented switching using the exact match forwarding algorithm 122 based on labels attached to incoming cells or frames. 124 A label switch may support multiple label types, however, each 125 switch port can support only one label type. The label type 126 supported by a given port is indicated by the switch to the 127 controller in a port configuration message. Connections may be 128 established between ports supporting different label types. 129 There are two forms of labels support; short 28 bit labels 130 which are sufficient for many purposes and TLV labels which are 131 defined for labels that do not fit in 28 bits. Examples of the 132 label types which use the short form include ATM, Frame Relay, 133 and MPLS Generic Labels. Examples of labels which use the TLV 134 form include DS1, DS3, E1, E3 and MPLS FECs. 136 A connection across a switch is formed by connecting an incoming 137 labelled channel to one or more outgoing labelled channels. 138 Connections are generally referenced by the input port on which 139 they arrive and the Labels values of their incoming labelled 140 channel. In some messages connections are referenced by the 141 output port. 143 GSMP supports point-to-point and point-to-multipoint connections. 144 A multipoint-to-point connection is specified by establishing 145 multiple point-to-point connections each of them specifying the 146 same output branch. A multipoint-to-multipoint connection is 147 specified by establishing multiple point-to-multipoint trees 148 each of them specifying the same output branches. 150 In general a connection is established with a certain quality of 151 service (QoS). This version of GSMP includes a default QoS 152 Configuration and additionally allows the negotiation of 153 alternative, optional QoS configurations. The default QoS 154 Configuration includes three QoS Models: a default service 155 model, a simple priority model and a QoS profile model. 157 GSMP contains an adjacency protocol. The adjacency protocol is 158 used to synchronise state across the link, to negotiate which 159 version of the GSMP protocol to use, to discover the identity 160 of the entity at the other end of a link, and to detect when it 161 changes. 163 3.1 Switch Partitioning 165 In this version of GSMP switch partitioning is static and occurs 166 prior to running GSMP. The partitions of a physical switch are 167 isolated from each other by the implementation and the controller 168 assumes that the resources allocated to a partition are at all 169 times available to that partition and only to that partition. A 170 partition appears to its controller as a physical label switch. 171 The resources allocated to a partition appear to the controller as 172 if they were the actual physical resources of the partition. For 173 example if the bandwidth of a port is divided among several 174 partitions, each partition would appear to the controller to have 175 its own independent port. 177 GSMP controls a partitioned switch through the use of a partition 178 identifier which is carried in every GSMP message. Each partition 179 has a one-to-one control relationship with its own logical 180 controller entity (which in the remainder of the document is 181 referred to simply as a controller) and GSMP independently 182 maintains adjacency between each controller-partition pair. 184 3.2 Switch and controller interactions 186 Multiple switches may be controlled by a single controller using 187 multiple instantiations of the protocol over separate control 188 connections. 190 Alternatively, multiple controllers can control a single switch. 191 Each controller would establish a control connection to the switch 192 using the adjacency protocol. The adjacency mechanism maintains a 193 state table indicating which the control connections that are 194 being maintained to the same partition. The switch provides 195 minimal information to the controller group about the number and 196 identity of the attached controllers. It does nothing, however, 197 to co-ordinate the activities of the controllers, and will execute 198 all commands as they are received. It is the controller group 199 responsibility to co-ordinate its use of the switch. This 200 mechanism is most commonly used for controller redundancy and load 201 sharing. Definition of the mechanism controllers use to co- 202 ordinate their control is not within GSMP's scope. 204 3.3 Service support 206 All GSMP switches must support the default QoS Configuration. A 207 GSMP switch may additionally support one or more alternative QoS 208 Configurations. GSMP includes a negotiation mechanism that allows 209 a controller to select from the QoS configurations that a switch 210 supports. 212 The default QoS Configuration includes three models: 214 The Service Model is based on service definitions found 215 external to GSMP such as in CR-LDP, Integrated Services or 216 ATM Service Categories. Each connection is assigned a 217 specific service that defines the handling of the 218 connection by the switch. Additionally, traffic parameters 219 and traffic controls may be assigned to the connection 220 depending on the assigned service. 222 In the Simple Abstract Model a connection is assigned a 223 priority when it is established. It may be assumed that for 224 connections that share the same output port, an cell or 225 frame on a connection with a higher priority is much more 226 likely to exit the switch before a cell or frame on a 227 connection with a lower priority if they are both in the 228 switch at the same time. 230 The QoS Profile Model provides a simple mechanism that allows 231 connection to be assigned QoS semantics defined external to 232 GSMP. Each profile is an opaque indicator which has been 233 predefined in the controller and in the switch. 235 4. Summary of Message Set 237 The following table gives a summary of the messages defined in 238 this version of the specification. It also makes a recommendation 239 of the minimal set of messages that should be supported in an MPLS 240 environment. These messages will be labelled as "Required", 241 though the service provided by the other messages are essential 242 for the operation of carrier quality controller/ switch 243 operations. V1.1 or V2 commands which are no longer support are 244 marked as "Obsolete" and should no longer be used. 246 4.1 Messages Table 248 Message Name Message Number Status 250 Connection Management Messages 251 Add Branch .......................16 Required 252 ATM Specific - VPC............26 253 Delete Tree.......................18 254 Verify Tree.......................19 Obsoleted 255 Delete All Input..................20 256 Delete All Output.................21 257 Delete Branches...................17 Required 258 Move Output Branch............... 22 259 ATM Specific - VPC............27 260 Move Input Branch.................23 261 ATM Specifc - VPC............28 263 Port Management Messages 264 Port Management...................32 Required 265 Label Range.......................33 267 State and Statistics Messages 268 Connection Activity...............48 269 Port Statistics...................49 Required 270 Connection Statistics.............50 271 QoS Class Statistics..............51 Reserved 272 Report Connection State...........52 274 Configuration Messages 275 Switch Configuration..............64 Required 276 Port Configuration................65 Required 277 All Ports Configuration...........66 Required 278 Service Configuration.............67 280 Reservation Messages 281 Reservation Request.............. 70 Required 282 Delete Reservation................71 Required 283 Delete All Reservations...........72 285 Event Messages 286 Port Up...........................80 287 Port Down.........................81 288 Invalid Label.....................82 289 New Port..........................83 290 Dead Port.........................84 292 Abstract and Resource Model Extension Messages 293 Reserved.Message Range.............200-249 295 Adjacency Protocol....................10 Required 297 5. Security Considerations 299 The security of GSMP's TCP/IP control channel has been addressed 300 in [4]. Any potential remaining security considerations are not 301 addressed in the current revision of this draft. 303 References 305 [1] Sjostrand, H., "Definitions of Managed Objects for the 306 General Switch Management Protocol (GSMP)," Internet-Draft 307 draft-ietf-gsmp-mib-01, March 2000. 309 [2] Newman, P, Edwards, W., Hinden, R., Hoffman, E. Ching 310 Liaw, F., Lyon, T. and Minshall, G., "Ipsilon's General 311 Switch Management Protocol Specification," Version 1.1, 312 RFC 1987, August 1996. 314 [3] Newman, P, Edwards, W., Hinden, R., Hoffman, E., Ching 315 Liaw, F., Lyon, T. and Minshall, G., "Ipsilon's General 316 Switch Management Protocol Specification," Version 2.0, 317 RFC 2397, March 1998. 319 [4] T. Worster, "GSMP Packet Encapsulations for ATM, Ethernet 320 and TCP," Internet-Draft draft-ietf-gsmp-encaps-00, Jan 321 2000. 323 [5] Doria, A, Sundell, K, Hellstrand, F, Worster, T, "General 324 switch Management Protocol V3," Internet Draft draft-ietf- 325 gsmp-04.txt, March 2000 327 [6] Worster, T,. " GSMP Packet Encapsulations for ATM, 328 Ethernet and TCP," Internet Draft draft-ietf-gsmp-encaps- 329 00.txt, October 1999 331 Authors' Addresses 333 Avri Doria 334 Nokia 335 5 Wayside Road 336 Burlington MA 01803 337 Phone: +1 781 993 4656 338 avri.doria@nokia.com 340 Kenneth Sundell 341 Nortel Networks AB 342 S:t Eriksgatan 115 A 343 P.O. Box 6701 344 SE-113 85 Stockholm Sweden 345 ksundell@nortelnetworks.com