idnits 2.17.1 draft-ietf-gsmp-applicability-01.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: ---------------------------------------------------------------------------- -- 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.) -- The document date (July 2000) is 8686 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-gsmp-mib-02 ** Downref: Normative reference to an Informational RFC: RFC 1987 (ref. '2') == Outdated reference: A later version (-05) exists of draft-ietf-gsmp-encaps-02 == Outdated reference: A later version (-11) exists of draft-ietf-gsmp-06 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Avri Doria 2 GSMP Working Group Kenneth Sundell 3 Informational Track Nortel Networks 4 July 2000 6 General Switch Management Protocol Applicability 8 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as "work 22 in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This memo provides an overview of the GSMP protocol and includes 33 information relating to its deployment in a MPLS environment. 35 1. Overview 37 The General Switch Management Protocol (GSMP) has been available 38 to the IETF community for several years now as informational 39 RFC's. Both GSMPv1.1 released in March 1996 as RFC1987 [2], and 40 GSMPv2.0 released in August 1998 as RFC2297 [3] are available. 41 Several vendors have implemented GSMPv1.1. 43 In V1.1 and V2 GSMP was intended only for use with ATM switches. 44 During the course of the last year, the GSMP working group has 45 decided to expand the purview of GSMP to the point where it can be 46 used to control a number of different kinds of switch and can thus 47 live up to what its name indicates; a general switch management 48 protocol. To do this, commands and arguments needed to be 49 generalised, with sections added discussing the manner in which 50 the generalised protocol could be applied to specific kinds of 51 switches and port types. In short the protocol has gone through 52 major changes in the last 24 months. 54 GSMP provides an interface that can be used to separate the data 55 forwarder from the routing and other control plane protocols such 56 as LDP. As such it allows service providers to move away from 57 monolithic systems that bundle control plane and data plane into a 58 single tightly coupled system - usually in a single chassis. 59 Separating the control components from the forwarding components 60 and using GSMP for switch management, enables service providers to 61 create multi-service systems composed of various vendors 62 equipment. It also allows for a more dynamic means of adding 63 services to their networks. 65 The IETF GSMP working group was established in the routing area 66 because GSMP was being seen as an optional part of the MPLS 67 solution. In a MPLS system, it is possible to run the routing 68 protocols and label distribution protocols on one system while 69 passing data across a generic switch, e.g. an ATM switch. GSMP 70 provides the switch resource management mechanism needed in such a 71 scenario. 73 GSMP has also been selected by the Multiservice Switching 74 Forum(MSF) as its protocol of choice for the Switch Control 75 Interface identified in their architecture. The MSF is an 76 industry forum, which among its activities establishes their 77 member's requirements and then works with the appropriate 78 standards bodies to foster their goals. In the case of GSMP, the 79 MSF presented the IETF GSMP Working Group with a set of 80 requirements for GSMP. The working group has made a determined 81 effort to comply with those requirements in its specifications. 83 2. GSMP V3 Document Set 85 The current version of GSMP is documented in 3 documents: 87 - GSMP: General Switch Management protocol V3 [5] 89 - GSMP-ENCAPS: GSMP Packet Encapsulations for ATM, Ethernet 90 and TCP[4] 92 - GSMP-MIB: Definitions of Managed Objects for the General 93 Switch Management Protocol [1] 95 3. General Description 97 The General Switch Management Protocol V3 (GSMPv3) [5], is a 98 general purpose protocol to control a label switch. GSMP allows 99 a controller to establish and release connections across the 100 switch; add and delete leaves on a multicast connection; 101 reserve resources; manage switch ports; request configuration 102 information; and request statistics. It also allows the switch 103 to inform the controller of asynchronous events such as a link 104 going down. The GSMP protocol is asymmetric, the controller 105 being the master and the switch being the slave. 107 A physical switch can be partitioned in many virtual switches. 108 GSMP does not provide support for defining switch partitions. 109 GSMP treats a virtual switch as if it were a physical switch. 111 GSMP may be transported in three ways: 113 - GSMP operation across an IP network is specified. 115 - GSMP operation across an ATM virtual channel is specified. 117 - GSMP operation across an Ethernet link is specified. 119 Other encapsulations are possible, but have not been defined. 120 Encapsulations are defined in [4]. 122 A label switch is a frame or cell switch that supports connection 123 oriented switching using the exact match forwarding algorithm 124 based on labels attached to incoming cells or frames. 126 A label switch may support multiple label types, however, each 127 switch port can support only one label type. The label type 128 supported by a given port is indicated in a port configuration 129 message. Connections may be established between ports 131 supporting different label types using the adaptation methods. 132 There are two forms of labels support; short 28 bit labels 133 which are sufficient for many purposes and TLV labels which are 134 defined for labels that do not fit in 28 bits. Examples of the 135 label types that can use the short form include ATM, Frame 136 Relay, and MPLS Generic Labels. Examples of labels which are 137 defined to use the TLV form include DS1, DS3, E1, E3 and MPLS 138 FECs. 140 A connection across a switch is formed by connecting an incoming 141 labelled channel to one or more outgoing labelled channels. 142 Connections are generally referenced by the input port on which 143 they arrive and the label values of their incoming labelled 144 channel. In some messages connections are referenced by the 145 output port. 147 GSMP supports point-to-point and point-to-multipoint connections. 148 A multipoint-to-point connection is specified by establishing 149 multiple point-to-point connections each of which specifies the 150 same output label. A multipoint-to-multipoint connection is 151 specified by establishing multiple point-to-multipoint 152 connections each of which specifies a different input label 153 with the same output labels. 155 In general a connection is established with a certain quality of 156 service (QoS). This version of GSMP includes a default QoS 157 Configuration and additionally allows the negotiation of 158 alternative, optional QoS configurations. The default QoS 159 Configuration includes three QoS Models: a default service 160 model, a simple priority model and a QoS profile model. This 161 version of GSMP also supports the reservation of resources when 162 the labels are not yet known. This ability can be used in 163 support of MPLS. 165 GSMP contains an adjacency protocol. The adjacency protocol is 166 used to synchronise state across the link, to negotiate which 167 version of the GSMP protocol to use, to discover the identity 168 of the entity at the other end of a link, and to detect when it 169 changes. 171 3.1 Switch Partitioning 173 In this version of GSMP switch partitioning is static and occurs 174 prior to running GSMP. The partitions of a physical switch are 175 isolated from each other by the implementation and the controller 176 assumes that the resources allocated to a partition are at all 177 times available to that partition and only to that partition. A 178 partition appears to its controller as a physical label switch. 179 The resources allocated to a partition appear to the controller as 180 if they were the actual physical resources of a physical switch. 181 For example if the bandwidth of a port is divided among several 182 partitions, each partition would appear to the controller to have 183 its own independent port with its fixed set or resources. 185 GSMP controls a partitioned switch through the use of a partition 186 identifier that is carried in every GSMP message. Each partition 187 has a one-to-one control relationship with its own logical 188 controller entity (which in the remainder of the document is 189 referred to simply as a controller) and GSMP independently 190 maintains adjacency between each controller-partition pair. 192 3.2 Switch and controller interactions 194 Multiple switches may be controlled by a single controller using 195 multiple instantiations of the protocol over separate control 196 connections. 198 Alternatively, multiple controllers can control a single switch. 199 Each controller would establish a control connection to the switch 200 using the adjacency protocol. The adjacency mechanism maintains a 201 state table indicating the control connections that are being 202 maintained by the same partition. The switch provides information 203 to the controller group about the number and identity of the 204 attached controllers. It does nothing, however, to co-ordinate 205 the activities of the controllers, and will execute all commands 206 as they are received. It is the controller group responsibility 207 to co-ordinate its use of the switch. This mechanism is most 208 commonly used for controller redundancy and load sharing. 209 Definition of the mechanism by which controllers use to co- 210 ordinate their control is not within GSMP's scope. 212 3.3 Service support 214 All GSMP switches must support the default QoS Configuration. A 215 GSMP switch may additionally support one or more alternative QoS 216 Configurations. GSMP includes a negotiation mechanism that allows 217 a controller to select from the QoS configurations that a switch 218 supports. 220 The default QoS Configuration includes three models: 222 The Service Model is based on service definitions found 223 external to GSMP such as in CR-LDP, Integrated Services or 224 ATM Service Categories. Each connection is assigned a 225 specific service that defines the handling of the 226 connection by the switch. Additionally, traffic parameters 227 and traffic controls may be assigned to the connection 228 depending on the assigned service. 230 In the Simple Abstract Model a connection is assigned a 231 priority when it is established. It may be assumed that for 232 connections that share the same output port, an cell or 233 frame on a connection with a higher priority is much more 234 likely to exit the switch before a cell or frame on a 235 connection with a lower priority if they are both in the 236 switch at the same time. 238 The QoS Profile Model provides a simple mechanism that allows 239 QoS semantics defined externally to GSMP to be assigned to 240 connections. Each profile is an opaque indicator that has 241 been predefined in the controller and in the switch. 243 4. Summary of Message Set 245 The following table gives a summary of the messages defined in 246 this version of the specification. It also makes a recommendation 247 of the minimal set of messages that should be supported in an MPLS 248 environment. These messages will be labelled as "Required", 249 though the service provided by the other messages are essential 250 for the operation of carrier quality controller/ switch 251 operations. GSMPv1.1 or GSMPv2 commands that are no longer 252 support are marked as "Obsolete" and should no longer be used. 254 4.1 Messages Table 256 Message Name Message Number Status 258 Connection Management Messages 259 Add Branch .......................16 Required 260 ATM Specific - VPC............26 261 Delete Tree.......................18 262 Verify Tree.......................19 Obsoleted 263 Delete All Input..................20 264 Delete All Output.................21 265 Delete Branches...................17 Required 266 Move Output Branch............... 22 267 ATM Specific - VPC............27 268 Move Input Branch.................23 269 ATM Specific - VPC............28 271 Port Management Messages 272 Port Management...................32 Required 273 Label Range.......................33 275 State and Statistics Messages 276 Connection Activity...............48 277 Port Statistics...................49 Required 278 Connection Statistics.............50 279 QoS Class Statistics..............51 Reserved 280 Report Connection State...........52 282 Configuration Messages 283 Switch Configuration..............64 Required 284 Port Configuration................65 Required 285 All Ports Configuration...........66 Required 286 Service Configuration.............67 288 Reservation Messages 289 Reservation Request.............. 70 Required 290 Delete Reservation................71 Required 291 Delete All Reservations...........72 293 Event Messages 294 Port Up...........................80 295 Port Down.........................81 296 Invalid Label.....................82 297 New Port..........................83 298 Dead Port.........................84 300 Abstract and Resource Model Extension Messages 301 Reserved.Message Range.............200-249 303 Adjacency Protocol....................10 Required 305 5. Security Considerations 307 The security of GSMP's TCP/IP control channel has been addressed 308 in [4]. Any potential remaining security considerations are not 309 addressed in the current revision of this draft. 311 References 313 [1] [GSMP-MIB] Sjostrand, H., "Definitions of Managed Objects 314 for the General Switch Management Protocol 315 (GSMP),"Internet-Draft draft-ietf-gsmp-mib- 316 02", July 2000. work in progress 318 [2] [GSMPv1.1] Newman, P, Edwards, W., Hinden, R., Hoffman, E. 319 Ching Liaw, F., Lyon, T. and Minshall, G., 320 "Ipsilon's General Switch Management Protocol 321 Specification," Version 1.1, RFC 1987, August 322 1996. 324 [3] [GSMPv2] Newman, P, Edwards, W., Hinden, R., Hoffman, 325 E., Ching Liaw, F., Lyon, T. and Minshall, G., 326 "Ipsilon's General Switch Management Protocol 327 Specification," Version 2.0, RFC 2397, March 328 1998. 330 [4] [GSMP-ENCAPS] T. Worster, "GSMP Packet Encapsulations for 331 ATM, Ethernet and TCP," Internet-Draft draft- 332 ietf-gsmp-encaps-02, July 2000. work in 333 progress 335 [5] [GSMP] Doria, A, Sundell, K, Hellstrand, F, Worster, 336 T, "General switch Management Protocol V3," 337 Internet Draft draft-ietf-gsmp-06.txt, July 338 2000. work in progress 340 Authors' Addresses 342 Avri Doria 343 Nortel Networks 344 600 Technology Park Drive 345 Billerica, MA 346 Phone: +1 401 663 5024 347 avri@nortelnetworks.com 349 Kenneth Sundell 350 Nortel Networks AB 351 S:t Eriksgatan 115 A 352 P.O. Box 6701 353 SE-113 85 Stockholm Sweden 354 ksundell@nortelnetworks.com