idnits 2.17.1 draft-ietf-gsmp-optical-spec-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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1080 has weird spacing: '...sharing worki...' -- 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 (March 2003) is 7706 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) == Unused Reference: '5' is defined on line 1170, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1183, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1191, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1194, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1198, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-gsmp-reqs-04 ** Downref: Normative reference to an Informational draft: draft-ietf-gsmp-reqs (ref. '2') == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-gmpls-architecture-03 == Outdated reference: A later version (-05) exists of draft-ietf-ipo-framework-03 ** Downref: Normative reference to an Informational draft: draft-ietf-ipo-framework (ref. '5') == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-lmp-07 -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: A later version (-05) exists of draft-ietf-ipo-impairments-04 ** Downref: Normative reference to an Informational draft: draft-ietf-ipo-impairments (ref. '9') -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Downref: Normative reference to an Informational RFC: RFC 3294 (ref. '11') == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-gmpls-recovery-terminology-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-gmpls-recovery-terminology (ref. '12') ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-recovery-frmwrk (ref. '13') Summary: 14 errors (**), 0 flaws (~~), 14 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 GSMP Working Group Internet Draft Jun Kyun Choi(ICU) 2 Document: draft-ietf-gsmp-optical-spec-01.txt Min Ho Kang(ICU) 3 Expiration Date: August 2003 Jung Yul Choi(ICU) 4 Gyu Myoung Lee(ICU) 5 Joo Uk Um(KT) 6 March 2003 8 General Switch Management Protocol (GSMP) v3 for Optical Support 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC-2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups MAY also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and MAY be updated, replaced, or obsolete by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work 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 document describes the GSMPv3 for the support of optical switching. 33 GSMPv3 controller SHOULD control optical label switches and manage 34 optical resources on them. This document describes the extended 35 functions of GSMPv3 for optical switching and explains operational 36 mechanisms to implement them. It SHOULD be referred with [1] for the 37 complete implementation. 39 Conventions 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in RFC-2119. 45 Table of Contents 47 1. Introduction.....................................................3 48 2. Common Definitions and Procedures for Optical Support............4 49 2.1 Labels.......................................................4 50 2.1.1 Labels for Fiber.........................................5 51 2.1.2 Labels for Waveband......................................5 52 2.1.3 Labels for Wavelength....................................6 53 2.1.4 Labels for optical burst switching.......................6 54 2.1.5 Label Range..............................................7 55 3. Connection Management Messages...................................8 56 3.1 Add Branch Message...........................................8 57 3.2 Delete Tree Message..........................................9 58 3.3 Delete All Input Port Message................................9 59 3.4 Delete All Output Port Message...............................9 60 3.5 Delete Branches Message......................................9 61 3.6 Move Output Branch Message...................................9 62 3.7 Move Input Branch Message...................................10 63 4. Reservation Management Messages.................................10 64 4.1 Reservation Request Message for optical burst...............10 65 4.2 Delete Reservation Message..................................12 66 4.3 Delete All Reservations Message.............................12 67 5. Management Message..............................................12 68 5.1 Port Management Message.....................................12 69 5.2 Label Range Message.........................................12 70 5.2.1 Optical Label...........................................12 71 6. State and Statistics Messages...................................13 72 6.1 Connection Activity Message.................................13 73 6.2 Statistics Messages.........................................13 74 6.2.1 Optical signal statistics Message.......................13 75 6.3 Report Connection State Message.............................14 76 7. Configuration Messages..........................................14 77 7.1 Optical Switch Configuration Message........................15 78 7.2 Port Configuration Message..................................16 79 7.2.1 PortType Specific Data for Optical Switching............16 80 7.3 All Ports Configuration Message.............................18 81 7.4 Service Configuration Message...............................18 82 7.4.1 Optical Service Configuration Message...................18 83 8. Event Messages..................................................18 84 8.1 Restoration Completion Message..............................18 85 8.2 Fault Notification Message..................................19 86 9. Optical Service Model Definition................................20 87 10. Failure Response Codes.........................................20 88 11. Security Considerations........................................20 89 Appendix I. Protection and Restoration Capability in GSMPv3........21 90 1.1 1+1 dedicated recovery mechanism............................21 91 1.2 1:1 dedicated recovery mechanism............................22 92 1.3 1:N/M:N shared recovery mechanism...........................23 93 Appendix II. GSMPv3 support for optical cross-connect system.......23 94 References.........................................................24 95 Acknowledgement....................................................25 96 Author's Addresses.................................................25 97 Full Copyright Statement...........................................27 99 1. Introduction 101 This document describes the extended functions and their mechanisms 102 of GSMPv3 for the support of optical switching. The GSMPv3 is an 103 asymmetric protocol to control and manage label switch. The label 104 switches that are used for optical switching are all optical cross- 105 connects (optical-optical-optical), transparent optical cross 106 connects (optical-electrical-optical, frame independent), and opaque 107 optical cross connects (optical-electrical-optical, SONET/SDH 108 frames).These OXC (optical cross connect) systems can be IP-based 109 optical routers which are dynamic wavelength routers, optical label 110 switches, or burst/packet-based optical cross connects, and so on[2]. 111 In this draft, we do not limit specific OXC systems, but aims to 112 provide the general functions of optical switching and services for 113 connections in general optical switches. 115 GSMPv3 is a label switch controller and provides a control interface 116 to optical switches. Therefore, it SHOULD define and add services for 117 optical switching and resource abstractions. The basic optical 118 resources used in connection setup are different with them of legacy 119 networks. In optical switching, basic connection units are a fiber, a 120 wavelength, or a burst and they are assumed to be processed in 121 optical domain without optical/electrical/optical conversion. It is 122 impossible to define services, traffic control, and QoS guarantee in 123 packet or cell level. New messages are needed to process optical 124 services, optical connection management, and so on, in real time 125 because optical switching requires real time process with low message 126 processing overhead. This draft describes optical resources, 127 connection management, optical services, and switch configuration 128 which can be applied in optical domain generally. 130 One of the important OAM functions is protection and restoration 131 functions. In the current situation where a single fiber delivers 132 several Tb/s through several wavelengths, when even a single link 133 gets cut it makes a huge turbulence. Therefore GSMPv3, as an optical 134 switch controller, MUST have protection and restoration capabilities 135 of switches and connections. By extending the management messages of 136 GSMP, this function will be implemented. This draft also deals with 137 several recovery capabilities of the GSMPv3. 139 For the complete implementation this document MUST be referred with 140 [1]. 142 2. Common Definitions and Procedures for Optical Support. 144 Common definitions and procedures which are not mentioned in this 145 document follow [1]. 147 2.1 Labels 149 Labels are the basic identifiers for connections. In order to setup 150 connections in optical switch, new labels MUST be defined. Newly 151 defined labels identify entities that are to be switched in optical 152 switches. GMPLS defines packet switching capable, TDM switching 153 capable, lambdas switching capable, fiber switching capable 154 interfaces, and it introduces needs of generalized labels to support 155 them [3][4]. So far, GMPLS does not defined labels to be used for 156 optical switching (label formats and encoding schemes), but GSMPv3 157 MUST support all types of label that to be defined in GMPLS. The 158 following lists, especially related to lambda/fiber switch capable 159 interfaces, are the labels to be supported in optical switching 160 [2][3][4][7][8][10]. 162 - a single fiber in a bundle 163 - a single waveband within a waveband (or )fiber 164 - a single wavelength within a fiber 165 - an optical burst within a wavelength 167 These labels can be encoded in a common structure composed of three 168 fields, a Type, a Length, and a Value [1]. TLV types for optical 169 support in GSMPv3 are not defined yet. 171 All labels will be designated as follow: 173 0 1 2 3 174 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |x|S|x|x| Label Type | Label Length | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | | 179 ~ Label Value ~ 180 | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 S: Stacked Label Indicator 184 S field is not used in this extended version of GSMPv3 because labels 185 for optical support only carry a single level of label [4]. 187 Label Type: 12 bit 188 Label type for optical support MAY be identified with the above four 189 types of optical switching. 190 Label type for optical support is TBD. 192 Label value: Variable 193 Carries label information. The interpretation of this field depends 194 on the type of the link (or the type of connection) over which the 195 label is used. Label value for optical support is TBD. 197 The other fields are defined in [1] and referred in it. 199 2.1.1 Labels for Fiber 201 This label indicates a fiber to be used for a connection 202 establishment in optical switching. The label value only has 203 significance between two neighbors, and the receiver MAY need to 204 convert the received value into a value that has local significance. 206 If the label type = labels for fiber, the label MUST be interpreted 207 as labels for fiber and the label for fiber has the following format: 209 0 1 2 3 210 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Label | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Label: 32 bits 216 Indicates a label for fiber to be used. 217 Label encoding is TBD. 219 2.1.2 Labels for Waveband 221 A waveband is a set of contiguous wavelengths which can be switched 222 together to a new waveband [3][4]. It MAY be desirable for an optical 223 cross connect to optically switch multiple wavelengths as a unit 224 since it MAY reduce distortion on individual wavelengths and MAY 225 allow tighter separation of individual wavelengths. Waveband 226 switching introduces another level of label hierarchy and as such the 227 waveband is treated the same way all other upper layer labels are 228 treated. The waveband label is defined to support such a waveband 229 switching. The waveband label can be encoded in three parts; waveband 230 ID, start label, and end label. The start label and the end label 231 represent the lowest value of wavelength and the highest value of 232 wavelengths. 234 If the label type = labels for waveband, the label MUST be 235 interpreted as labels for waveband and the label for waveband has the 236 following format: 238 0 1 2 3 239 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Waveband Id | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Start Label | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | End Label | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Waveband Id: 32 bits 249 A waveband identifier. The value is selected by a sender and reused 250 in all subsequent related messages. 252 Start Label: 32 bits 253 Indicates the lowest value of wavelength in the waveband. 255 End Label: 32 bits 256 Indicates the highest value wavelength in the waveband. 258 The start/end label are established either by configuration or by 259 means of a protocol such as LMP [6]. They are normally used in the 260 label parameter of the Generalized Label one PSC and LSC [3][4]. 262 2.1.3 Labels for Wavelength 264 The label indicates a single wavelength to be used for a connection 265 establishment in optical switching. The label value only has 266 significance between two neighbors, and the receiver MAY need to 267 convert the received value into a value that has local significance. 269 If the label type = labels for wavelength, the label MUST be 270 interpreted as labels for wavelength and a format of the label for 271 wavelength is given as the below: 273 0 1 2 3 274 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Label | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Label: 32 bits 280 Indicates label for wavelength to be used. 281 Label encoding is TBD. 283 2.1.4 Labels for optical burst switching 285 The label for optical burst switching represents a label for 286 switching optical burst data. 288 Optical data burst switching, which utilizes finer granularity in 289 time domain in a coarse granularity such as a wavelength, is a new 290 connection entity in optical domain [7][8]. Connection setup for 291 optical burst includes reserving time on the transport medium for the 292 client. 294 This time is characterized by two parameters: start time and duration 295 of data burst. These values define a fast one-way reservation. Upon a 296 request for setup of a burst connection, the GSMP controller MUST 297 perform appropriate Connection Admission Control for the start time 298 and duration of data burst specified. If the connection is allowed, 299 it MUST signal these parameters to the burst switching device to 300 reserve the exact bandwidth required [7][8]. The burst switch MUST 301 perform the switching operation autonomously, using the 302 synchronization methods prescribed for the burst network it is 303 operating in. 305 If the label type = labels for optical burst switching, the label 306 MUST be interpreted as labels for burst switching and a format of the 307 label for optical burst switching is given as the below: 309 0 1 2 3 310 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Label | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Label: 32 bits 316 Indicates label for a burst level connection. 317 Label encoding is TBD. 319 2.1.5 Label Range 321 The basic label range to be used in each port is specified by the 322 Port Configuration or All Port Configuration message. The Label Range 323 message allows the range of labels supported by a specified port to 324 be changed. The controller MUST allocate the label range with 325 consideration of optical characteristics when assigning the labels 326 for a connection because a connection is established per optical 327 burst, wavelength, waveband, and fiber in optical domain. Since the 328 basic label range varies in switches and the labels for the 329 connections can be different due to the optical characteristics, GSMP 330 does not treat them. However, the following lists SHOULD be 331 considered and the available label ranges SHOULD be applied in the 332 Label Range message. 334 - When allocating a label for a wavelength, the label SHOULD be 335 allocated with consideration of wavelength continuity. For 336 satisfying requirement of wavelength continuity in a connection, 337 the label SHOULD be allocated to maintain the same wavelength for 338 it. The controller MUST manage the available labels and support 339 the constraint. 341 - The labels to be used for waveband switching MUST be contiguous, 342 because the waveband switching is possible only in a set of 343 contiguous wavelengths. The decision mechanism for the available 344 label range is out of scope of GSMPv3. 346 - GMPLS supports bi-directional symmetric LSPs setup [3][4]. To 347 setup a bi-directional LSP two unidirectional paths MUST be 348 independently established. For doing so, the presence of an 349 upstream label in the appropriate signaling message indicates the 350 bi-directional LSP setup and two labels are allocated for them. 351 The GSMPv3, therefore, SHOULD allow appropriate labels for them. 352 In order to avoid contention for labels, much care SHOULD be taken 353 in choosing the two labels. To choose the labels to avoid 354 contention is out of scope of GSMPv3. 356 3. Connection Management Messages 358 Connection management messages, which are used for establishing, 359 releasing, modifying, and verifying connections across the switch by 360 the controller, SHOULD operate for optical switching. Since the 361 GSMPv3 does not process each packet in optical domain, traffic 362 related fields used to specify connections in the messages are not 363 dealt with and then it makes possible to process the message faster. 364 Connection management messages also SHOULD support restoration 365 capabilities of optical switch and these are mainly dealt with in the 366 following sub-sections. 368 The general message definition and semantics in this section follow 369 [1] and the other untouched items are dealt with in it. 371 3.1 Add Branch Message 373 The Add Branch message is used to setup a connection. Especially, it 374 SHOULD support restoration capability in optical switches. For 1+1 375 dedicated recovery, it is required to make an additional connection 376 as a backup connection to protect an original connection against a 377 failure. Additional fields are not required in the Add Branch message 378 to support the restoration capability since two connections are used 379 for delivering data traffic simultaneously and an egress node selects 380 one of them. Since the two connections are established for one 381 connection, connection-related fields, such as input port/label, 382 output port/label, SHUOLD be carefully set in order to distinguish 383 them. The controller SHOULD know the whole status of the switch and 384 manage the information base. 386 3.2 Delete Tree Message 388 The message format and semantics in this section follows [1]. 390 3.3 Delete All Input Port Message 392 The message format and semantics in this section follows [1]. 394 3.4 Delete All Output Port Message 396 The message format and semantics in this section follows [1]. 398 3.5 Delete Branches Message 400 The message format and semantics in this section follows [1], and 401 optical switching related contents will be added. 403 3.6 Move Output Branch Message 405 The Move Output Branch message is used to change the current output 406 port label to the new output port label for re-establishing the 407 existing connection. It can be used to support restoration capability. 408 Since to re-establish output port of a switch at an ingress node is 409 to change a start point of the current connection, it can be used for 410 1:1 dedicated recovery or 1:N (M:N) shared recovery where an ingress 411 node begins a connection and it takes responsibility for recovery of 412 the connection. Upon a fault occurring, in order to setup a new 413 backup connection for the failed working connection, the new port in 414 upstream node SHOULD be connected to the current connection by using 415 this message. 417 For configuring a new backup connection, the following fields of Move 418 Input Branch message SHOULD be set as following. 420 - Old Output Port = failed working connection's output port ID 421 - Old Output Label = failed working connection's output label ID 422 - New Output Port = newly configured reserved backup connection's 423 output port ID 424 - New Output Port = newly configured reserved backup connection's 425 output label ID 427 This message is additionally used to move back to the original 428 connection from the backup connection in revertible mode after a 429 recovery completed. In this case, Old Output Port/Label are for the 430 currently used backup connection, and New Output Port/Label are for 431 the restored working connection 433 3.7 Move Input Branch Message 435 The Move Input Branch message is used to change the current input 436 port label to the new input port label for re-establishing the 437 existing connection. It is also used to support restoration 438 capability. For 1:1 dedicated recovery or 1:N (M:N) shared recovery, 439 the message can be used to configure backup connection at an egress 440 node. By setting Old Input Port/Label as a failed working connection 441 and New Input Port/Label as a reserved backup connection, recovery of 442 the failed working connections is achieved. 444 It is also used to move back to the original connection from a backup 445 connection for the revertible mode after a recovery completed. The 446 new port/label in this message sets that of the restored original 447 connection. 449 The other untouched items and fields in these messages are dealt with 450 in [1] and referred in it. 452 4. Reservation Management Messages 454 The GSMPv3 allows a switch to reserve resources for connections 455 before establishing them through Reservation Management messages. 456 Reservable resources are bandwidth, buffers, queues, labels and etc. 457 In this extended version of GSMPv3 for optical support, the resources 458 imply optical resources, such as data burst, wavelengths, fibers, and 459 so on. 461 With these messages, restoration capabilities of a switch are 462 supported. Especially, in 1:N (M:N) shared recovery scheme, a spare 463 connection is reserved for N working connections. The GSMPv3 SHOULD 464 use the reservation request messages for reserving a backup 465 connection. The GSMPv3 controller SHOULD have mapping information 466 between a shared backup resource and N working connections. Whenever 467 the GSMPv3 uses the reserved resource for a failed working connection 468 Add Branch message is used to establish a new connection with New 469 Port/Label of one of N working connections. 471 Or any other cases, the reserved resources are used as followed in 472 [1]. The message format and semantics in this section follow [1] and 473 the other untouched items are dealt with in it. 475 4.1 Reservation Request Message for optical burst 477 Reservation Request message SHOULD support new connections per data 478 burst, based on time-delayed reservation in optical domain. In order 479 to configure connection per burst, two parameters, offset time and 480 burst length, SHOULD be add on the message. When a controller 481 receives a request for a burst connection setup it sends a 482 Reservation Request message with the two fields. The switch then 483 waits for offset time to establish the connection and then 484 automatically set it up. After burst length time, it releases the 485 connection. 487 Message type = TBA 489 The Reservation Request message for optical burst has the following 490 format. 492 0 1 2 3 493 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Version | Message Type | Result | Code | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Partition ID | Transaction Identifier | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 |I| SubMessage Number | Length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Port Session Number | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Reservation ID | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Input Port | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Input Service Selector | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Output Port | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Output Service Selector | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 |IQS|OQS|P|x|N|O| Adaptation Method | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 |x|S|M|B| | 516 +-+-+-+-+ Input Label | 517 ~ ~ 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 |x|S|M|x| | 520 +-+-+-+-+ Output Label | 521 ~ ~ 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Offset Time (T) | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Burst Length (L) | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 Note: Fields and Parameters that have not been explained in the 529 Subsection follow [1]. 531 Offset Time (T); TBD 532 This field is the time between a connection request reception and the 533 start of the connection for the data burst. 535 Burst Length (L); TBD 536 This field is the time duration of data burst 538 4.2 Delete Reservation Message 540 The message format and semantics in this section follows [1]. 542 4.3 Delete All Reservations Message 544 The message format and semantics in this section follows [1]. 546 5. Management Message 548 5.1 Port Management Message 550 The message format and semantics in this section follows [1], and 551 optical switching related contents will be added. 553 5.2 Label Range Message 555 The label range, which is specified for each port by the Port 556 Configuration or the All Ports Configuration message, can be 557 specified to the range of label supported by a specified port and to 558 be changed by using Label Range message. Since the granularity of 559 each connection is different in optical domain each port SHOULD allow 560 the label range changeable in ports. In addition, a port MAY have 561 wavelength converters with full or limited capability so that each 562 port MAY have different limited labels. In case of waveband switching, 563 a single label for waveband connection is used for a set of 564 wavelengths in the band. To support these cases, the Label Range 565 message is used. 567 The general usage and massage format of this message follows [1]. 569 5.2.1 Optical Label 571 If the Label Type is equal to optical label, the label range message 572 MUST be interpreted as an Optical Label. Label Range Message format 573 follows [1] and the Label Range Block has the following format: 575 0 1 2 3 576 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 |x|x|V|C| Optical Label | Label Length | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Min Label | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Max Label | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Remaining Labels | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 V: Label 588 The Label flag use is port type specific. 589 TBD. 591 C: Multipoint Capable 592 Indicates label range that can be used for multipoint connections. 593 This field is not used in the draft. 595 Min Label: TBD 596 The minimum label value in the range. 598 Max Label: TBD 599 The maximum label value in the range. 601 Remaining Labels: TBD 602 The maximum number of remaining labels that could be requested for 603 allocation on the specified port. 605 6. State and Statistics Messages 607 The State and Statistics messages allow a controller to request state 608 and statistics of connections of a switch. They SHOULD be extended to 609 monitor the statistics related to ports and connections for optical 610 transmission. 612 6.1 Connection Activity Message 614 The message format and semantics of the message follows [1], and 615 optical switching related contents will be added. 617 6.2 Statistics Messages 619 6.2.1 Optical signal statistics Message 621 The statistics messages are used to query the performance statistics 622 related to ports and connections for optical transmission. Since the 623 current statistics messages in [1] report the statistics related to 624 traffic states per cells, or frames, new fields SHOULD be added into 625 the message for querying optical support. The statistics contain 626 optical transmission characteristics which specify transmission QoS 627 of connections. Transmission performance is typically defined in 628 terms of signal performance with reference to noise level, or by the 629 signal-to-noise ratio (SNR), and spectral occupancy requirement or 630 signal power level. Optical Signal Statistics message SHOULD contain 631 Optical Signal Property which specifies the transmission property of 632 connections as shown in the below. 634 Optical Signal Statistics Message Type = TBA 636 0 1 2 3 637 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Version | Message Type | Result | Code | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Partition ID | Transaction Identifier | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 |I| SubMessage Number | Length | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Port | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 |x|S|x|x| | 648 +-+-+-+-+ Label | 649 ~ ~ 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | | 652 ~ Optical Signal Property ~ 653 | | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Optical Signal Property; variable 657 This field implies quality of transmission signal in a connection so 658 that it informs a controller signal degradation or loss of signal. 659 This field MAY consist of several sub-TLVs which specify the optical 660 signal statistics in detail and they will be further added on this 661 message. This information MAY result in an alarm of link failure. 663 The format and semantics of Optical Signal Property is TBD. 665 The other statistics messages are not dealt with in the section 666 follow [1]. 668 6.3 Report Connection State Message 670 The message format and usage in this section follows [1], and optical 671 switching related contents will be added. 673 7. Configuration Messages 674 The configuration messages allow a controller to discover a 675 capabilities of optical switch. Switch configuration, port 676 configuration, and service configuration messages are defined for 677 these functions. 679 7.1 Optical Switch Configuration Message 681 Since an optical switch MAY be able to provide connection services at 682 multiple transport layers, and not all switches are expected to 683 support the same transport layers, the switch will need to notify the 684 controller of the specific layers it can support. Therefore, the 685 switch configuration message MUST be extended to provide a list of 686 the transport layers for which an optical switch can perform 687 switching. For supporting various types of switching capable 688 interfaces, Optical Switch Configuration Message SHOULD contain the 689 Switching Interface ID. 691 Message Type = TBD 693 0 1 2 3 694 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Version | Message Type | Result | Code | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Partition ID | Transaction Identifier | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 |I| SubMessage Number | Length | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | MType | MType | MType | MType | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Firmware Version Number | Window Size | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Switch Type | | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 708 | Switch Name | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Max Reservations | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | | 713 ~ Optical Switching Interface IDs ~ 714 | | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 Optical Switching Interface ID: variable 718 TBD 720 The following lists are the possible switching capable layers. 722 - switching per optical burst 723 - switching per a single wavelength 724 - switching per a waveband 725 - switching per a single fiber 726 - switching per a fiber bundle 728 7.2 Port Configuration Message 730 The port configuration message informs a controller configuration 731 information related to a single port. Ports in optical switches 732 differ from those in electrical switches. The ports defined in GSMPv3 733 imply a single physical link and several connections are specified 734 with labels in a port. However, a single port does not identify a 735 single link in optical domain. A port can imply a set of fibers, a 736 single fiber, or a single wavelength. Therefore different types of 737 port SHOULD be identified in GSMPv3. Moreover, OXC can have many bays 738 which contain hundreds of shalves which have tens of thousands of 739 port. Therefore, physical bay and shelve identifiers also SHOULD be 740 defined and encoded in the port configuration message. 742 The basic format and usage of Port Configuration message follow [1]. 743 The following new port types are defined. In optical domain, PortType 744 can be classified into per fiber bundle containing several fibers, a 745 single fiber containing several wavelengths, or a single wavelength. 747 PortType = optical switching (TBA by IANA) 749 This port type further can be classified into several types as 750 following. 752 PortType = fiber in optical switching 753 PortType = wavelength in optical switching 754 ... 756 7.2.1 PortType Specific Data for Optical Switching 758 The format and usage of Port Specific Data in Port Configuration 759 message depends on the PortType value and the basic format of it is 760 given as following [1]. 762 0 1 2 3 763 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 |P|M|L|R|Q| Label Range Count | Label Range Length | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | | 768 ~ Default Label Range Block ~ 769 | | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Receive Data Rate | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Transmit Data Rate | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Port Status | Line Type | Line Status | Priorities | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Physical Slot Number | Physical Port Number | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 Note: Fields and Parameters that have not been explained in the 781 Subsection follow [1]. 783 In this section, we specify some fields for supporting optical 784 switching as following. If PortType is equal to optical switching, 786 Receive Data Rate 787 The maximum rate of data that may arrive at the input port 788 (interface) in; 790 Bits/sec for PortType = Optical Switching 792 Transmit Data Rate 793 The maximum rate of data that may depart from the output port 794 (interface) in; 796 Bits/sec for PortType = Optical Switching 798 Line Type 799 The type of physical transmission interface for this port. The line 800 type for optical support depends on switching interface for each 801 switching entity, such as for wavelength-related port or fiber- 802 related port. This field MAY define bit rate of wavelength, fiber 803 type. The following values can be identified for optical support. 805 PortType = Optical Switching: TBD 807 Physical Slot Number 808 The physical location of the slot in optical switching (or OXC). 809 Since the OXC systems can have many bays which contain hundreds of 810 shelf which have tens of thousands of port this field SHLOULD 811 identify the slot. For doing so, the field MAY be partitioned into 812 several sub-fields to define bay, shelf, and slot. 814 The default label range block for optical switching has the 815 following format. 817 0 1 2 3 818 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 |x|x|x|x| Label Type | Label Length | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | | 823 ~ Label Value ~ 824 | | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 Label Type: 12 bit 828 Label type for optical support. Each encoding type of the labels is 829 TBD. 831 Label value: Variable 832 Carries label information. The interpretation of this field depends 833 on the type of the link (or the type of connection) over which the 834 label is used. Min Label and Max label value imply the range of 835 available optical labels. Each encoding type of the labels is TBD. 837 7.3 All Ports Configuration Message 839 The message format and usage of it follows [1], and optical 840 switching-related contents follow section 7.2. 842 7.4 Service Configuration Message 844 The Service Configuration message requests an optical switch report 845 the configuration information of the supported services. The 846 requested services are identified in service ID in the Add Branch 847 message or the Reservation Management message. The service model is 848 defined with traffic parameter, QoS parameter, and traffic control 849 elements in [1], but these parameters can not be used to specify the 850 optical services. Therefore this message SHOULD be modified to 851 support optical services with newly defined capability sets. The 852 services supported at optical switches SHOULD be defined for dealing 853 with optical burst, wavelength, waveband, and fiber connection. 855 7.4.1 Optical Service Configuration Message 857 TBD. 859 8. Event Messages 861 The Event messages allow a switch to inform a controller of certain 862 asynchronous events. In this version of GSMPv3, asynchronous events 863 mainly deal with recovery-related events. The indication of these 864 asynchronous events related to ports and switch elements can inform 865 failure of them to the controller and it can initiate a fault 866 recovery mechanism. The basic message format and usage of it SHOULD 867 be referred to [1]. The two messages, Restoration Completion message 868 and Fault Notification message, are used to notify a controller 869 fault-related events of a switch. 871 8.1 Restoration Completion Message 872 For 1+1 dedicated recovery, a failed working connection is switched 873 over to another dedicated connection without a controller's 874 recognition. This message is used to inform the controller 875 restoration completion of the switch. This message contains failed 876 working connection ID and restored backup connection ID. 878 Message Type = TBA 880 If a message type is equal to Restoration Completion message the 881 following sub-TLVs SHOULD be added on the message in order to notify 882 restoration completion to a controller. 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | | 886 ~ Restored Port ID list ~ 887 | | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | | 890 ~ Restored Switch Element ID list ~ 891 | | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 8.2 Fault Notification Message 896 This message is used to inform a controller a fault occurring in a 897 switch. The possible faults are link failure from cutting off 898 (affecting wavelengths, fibers, fiber bundles), port failure, or 899 switch modules. For the notification purpose, the following sub-TLV 900 SHOULD be added in Event message. 902 Message type = TBA 904 If a message type is equal to Fault Notification message the 905 following sub-TLV SHOULD be added on the message in order to notify a 906 fault in a switch to a controller. 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Failed Port ID list | 910 ~ ~ 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Failed Switch Element ID list | 913 ~ ~ 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 Failed Port ID list; variable 917 This field describes the failed port ID which contains different 918 types of port which indicate wavelength-related port, fiber-related 919 port, or fiber bundle-related port. This field can consist of several 920 sub-TLVs to indicate the failed elements. 922 Failed Switch Element ID list; variable 923 This field describes the failed optical switch fabric such as, 924 wavelength converters, cross connect elements, and so on. It depends 925 on the optical switching systems. 927 The encoding of Failed Switch Element is TBD 929 9. Optical Service Model Definition 931 TBD 933 10. Failure Response Codes 935 This chapter describes the failure and warning states which can occur 936 in setup optical connections. The following lists are the codes that 937 SHOULD be defined and added in the Failure Response messages. These 938 codes MAY be added more when the services for optical switching are 939 defined. 941 If the switch issues a failure response it MUST choose the most 942 specific failure code according to the following precedence. The code 943 numbers will be assigned in IANA. 945 Optical Connection Failure 947 - recovery failure 948 Due the limitation of available resource for backup connection, 949 for example, multiple links failure, the switch can not be 950 succeeded the recovery procedure for shared protected connection. 952 - waveband connection setup failure 953 There are not available wavelengths which belong to the range of 954 min and max limits of the waveband 956 - reservation failure for optical burst 957 In case of delayed reservation in time is not exactly matched, 958 the reservation of optical burst can be failed. 960 The following list gives a summary of the failure codes defined for 961 failure response messages: 963 - no available label for shortage of available wavelengths 964 - no available resource for recovery 965 - no available resource for waveband connection setup 966 - no match for the delayed reservation for optical burst connection 968 11. Security Considerations 969 This document does not have any security concerns. The security 970 requirements using this document are describes in the referenced 971 documents. 973 Appendix I. Protection and Restoration Capability in GSMPv3 975 The GSMP controller MUST support the protection and restoration 976 capabilities because the optical switch delivers several Gbps data 977 traffic in a single wavelength. To achieve fast protection and 978 restoration, the optical switch is capable of taking an action 979 independent of the GSMP controller, then it informs the controller 980 after completing the restoration [2]. This differs from the master- 981 slave relationship in GSMP. 983 Recovery mechanisms do not distinguish path (end-to-end) and link 984 recovery in GSMPv3. The difference of them is considered in signaling 985 protocol. In case of dynamically calculating the backup link after a 986 fault occurs, GSMPv3 establishes a new backup link by using the 987 existing Add Branch message. Therefore, this draft considers pre- 988 planned recovery mechanisms, such as 1+1 dedicated recovery, 1:1 989 dedicated recovery with/without extra traffic, and 1:N/M:N shared 990 recovery. 992 The label switch SHOULD provide the protection and restoration 993 capabilities in order to provide the recovery mechanisms. For example, 994 an ingress/egress node reserves backup resources according the each 995 recovery mechanism, and setup the switch fabric. Then, GSMPv3 is used 996 to control the switch. 998 In this section, the recovery mechanisms which can be provided by 999 GSMPv3 is specified with including a fault notification, and 1000 restoration, and related required messages. For example, the port 1001 configuration command MUST be extended to allow autonomous protection 1002 mechanism. The current GSMP connection management also MUST be 1003 extended to support this function. In the following subsections, the 1004 supported recovery mechanisms in GSMPv3 are introduced. 1006 1.1 1+1 dedicated recovery mechanism 1008 In this recovery mechanism, GSMPv3 utilizes the existing Connection 1009 Management messages. It is not necessary to notify a fault to the 1010 controller and restore the failed working link at physical layer. 1011 Then, the switch notifies the recovery completion to the controller 1012 by using Event message. The recovery procedure of the mechanism 1013 follows. 1015 - Backup link configuration 1016 Use Add Branch message as for working link. 1018 - Fault notification 1019 Let physical layer process before GSMPv3 recognizes. 1021 - Recovery procedure 1022 Let physical layer process before GSMPv3 recognizes. 1024 - After recovery completion; 1025 Firstly, the switch notifies recovery completion to the controller by 1026 using Restoration Completion message, then 1028 * Revertible mode; GSMPv3 uses Move Input message to switch the 1029 currently used backup link to the restored working link at an 1030 egress node. 1032 * Non-revertible mode; GSMPv3 deletes the restored working link by 1033 using Delete Branch message, and then configures a new backup 1034 link by using Add Branch message. 1036 1.2 1:1 dedicated recovery mechanism 1038 - Backup link configuration 1039 An ingress/egress node configure a backup link by using Reservation 1040 Request message, and core nodes use Add Branch message to reserve 1041 backup link. In this recovery mechanism, extra traffic can be 1042 delivered through the backup link. If it could be possible, core 1043 nodes use Reservation request message, not Add Branch message. 1044 However this draft only considers the former case as this mechanism. 1046 - Fault notification 1048 * Fault detected from signaling protocol; GSMPv3 have already 1049 known the fault, it directly go into the recovery procedure. 1051 * Fault detected from the switch; Event message (esp. Fault 1052 Notification message) is used to notify the fault to the 1053 controller. 1055 - Recovery procedure 1056 An ingress node uses Move Output message and an egress node used Move 1057 Input message in order to configure a backup link. Since the backup 1058 path is configured through the network, core nodes do not take any 1059 action for recovery. 1061 - After recovery completion 1062 Firstly, the switch notifies recovery completion to the controller by 1063 using Restoration Completion message, then 1065 * Revertible mode; GSMPv3 uses Move Input message (at an ingress 1066 node) and Move Output message (at an egress node) to switch the 1067 currently used backup link to the restored working link at 1068 destination node. The backup link is still used for backup by 1069 using Reservation Request message. 1071 * Non-revertible mode; Delete Branch message can be used to delete 1072 the restored working link. GSMPv3 uses Reservation Request 1073 message to reserve new backup link for the working link. 1075 1.3 1:N/M:N shared recovery mechanism 1077 - Backup link configuration 1078 Reservation Request message is used to configure a backup link. Since 1079 several working links (= N) share one backup link (1:N) or several 1080 backup links (M:N) GSMPv3 SHUOLD know the sharing working link IDs 1081 for the backup links. Resource management of GSMPv3 is out of scope 1082 of this draft. 1084 - Fault notification 1086 * Fault detected from signaling protocol; GSMPv3 have already 1087 known the fault, it directly go into the recovery procedure. 1089 * Fault detected from the switch; Event message (esp. Fault 1090 Notification message) is used to notify the fault to the controller. 1092 - Recovery procedure 1093 When GSMPv3 is notified a fault, it uses Add Branch message to 1094 configure a new working link by using reserved backup link. 1096 - After recovery completion 1097 Firstly, the switch notifies recovery completion to the controller by 1098 using Restoration Completion message, then 1100 * Revertible mode; GSMPv3 uses Move Input message (at an ingress 1101 node) and Move Output message (at an egress node) to switch the 1102 currently used backup link to the restored working link at 1103 destination node. The backup link is still used for shared 1104 backup by using Reservation Request message. 1106 * Non-revertible mode; Delete Branch message can be used to delete 1107 the restored working link. GSMPv3 uses Reservation Request 1108 message to reserve new backup link for the working link. 1110 Appendix II. GSMPv3 support for optical cross-connect system 1112 The GSMPv3 controls and manages the optical cross-connect systems as 1113 label switches. The optical cross-connect (OXC) is a space division 1114 switch that can switch an optical data stream on an input port to an 1115 output port. The OXCs are all optical cross-connects (optical- 1116 optical-optical), transparent optical cross connects (optical- 1117 electrical-optical, frame independent), and opaque optical cross 1118 connects (optical-electrical-optical, SONET/SDH frames).These OXC 1119 (optical cross connect) systems can be IP-based optical routers which 1120 are dynamic wavelength routers, optical label switches, or 1121 burst/packet-based optical cross connects, and so on[2]. 1123 The OXC system consists of switching fabric, multiplexer/ 1124 demultiplexer, wavelength converter, and optical-electrical/ 1125 electrical-optical converter. Multiple wavelengths are multiplexed or 1126 demultiplexed into a fiber. Multiple fibers belong to a fiber bundle. 1127 A wavelength, a waveband, and a fiber can be used to establish a 1128 connection in an optical switch. They SHOULD be recognized at a port 1129 in the OXC since they are connection entities. When the OXC has 1130 optical-electrical conversion at the input port and electrical- 1131 optical conversion at the output port it is called as opaque OXC. Or, 1132 when it processes optical data stream all optically it is called as 1133 transparent OXC. Wavelength converter SHOULD be used to resolve 1134 output port contention when two different connections try to be 1135 established in a same output port. Since the wavelength converter can 1136 work only within a limited operating range, the limited numbers of 1137 wavelengths are used at the output port. It limits the available 1138 wavelengths at the output port. 1140 If OXCs perform protection and restoration functions they SHOULD have 1141 suitable switch structure to support them. In case of 1+1 dedicated 1142 recovery, input ports and output ports MUST be duplicated in a switch. 1143 The switch transmits optical signal through two ports (one for 1144 working connection and another for backup connection) simultaneously. 1145 When a fault happens the switch switches over from failed working 1146 connection to dedicated backup connection without noticing a 1147 controller. 1149 In order to control and manage the OXC systems, GSMP SHOULD be 1150 located as a subset of functions for it and MUST know the current 1151 switch, port and service configuration information. GSMP controller 1152 SHOULD identify the connection entities at the OXC and match them 1153 with the optical labels. 1155 References 1157 [1] Doria, A, Sundell, K, Hellstrand, F, Worster, T, "General Switch 1158 Management Protocol V3", RFC 3292, June 2002. 1160 [2] Georg Kullgren, et. al., "Requirements For Adding Optical Support 1161 To GSMPv3",draft-ietf-gsmp-reqs-04.txt (work in progress), Nov. 2002. 1163 [3] Mannie, E., et. al., "Generalized Multi-Protocol Label Switching 1164 (GMPLS) Architecture", draft-ietf-ccamp-gmpls-architecture-03.txt 1165 (work in progress), August 2002. 1167 [4] Ashwood-Smith, D., et. al., "Generalized MPLS - Signaling 1168 Functional Description", RFC3471, Jan. 2003. 1170 [5] Rajagopalan, B., et. al., "IP over Optical Networks: A Framework", 1171 draft-ietf-ipo-framework-03.txt (work in progress), Jan. 2003. 1173 [6] J. Lang, et. at. "Link Management Protocol (LMP) ", draft-ietf- 1174 ccamp-lmp-07.txt (work in progress), November 2002. 1176 [7] C. Qiao, M. Yoo, "Choice, and Feature and Issues in Optical Burst 1177 Switching", Optical Net. Mag., vol.1, No.2, Apr.2000, pp.36-44. 1179 [8] OBS Ilia Baldine, George N. Rouskas, Harry G. Perros, Dan 1180 Stevension, "JumpStart: A Just-in-time Signaling Architecture for WDM 1181 Burst-Switching Networks", IEEE Comm. Mag., Feb. 2002. 1183 [9] Angela Chiu, John Strans, et. al., "Impairments And Other 1184 Constraints On Optical Layer Routing", draft-ietf-ipo-impairments- 1185 04.txt (work in progress), Dec. 2002. 1187 [10] Daniel Awduche, WYakov Rekhter, "Multiprotocol Lambda Switching: 1188 Combining MPLS Traffic Engineering Control with Optical 1189 Crossconnects", IEEE Comm. Mag., March 2001 1191 [11] Doria, A. and K. Sundell, "General Switch Management Protocol 1192 Applicability", RFC 3294, June 2002. 1194 [12] Mannie, E., et. al., "Recovery (Protection and Restoration) 1195 Terminology for GMPLS", draft-ietf-ccamp-gmpls-recovery-terminology- 1196 00.txt (work in progress), June 2002 1198 [13] Vishal Sharma, et. at., "Framework for MPLS-based Recovery", 1199 draft-ietf-mpls-recovery-frmwrk-08.txt (work in progress), October 1200 2002 1202 Acknowledgement 1204 This work was supported in part by the Korean Science and Engineering 1205 Foundation (KOSEF) through OIRC project 1207 Author's Addresses 1209 Jun Kyun Choi 1210 Information and Communications University (ICU) 1211 58-4 Hwa Ahm Dong, Yusong, Daejon 1212 Korea 305-732 1213 Phone: +82-42-866-6122 1214 Email: jkchoi@icu.ac.kr 1215 Min Ho Kang 1216 Information and Communications University (ICU) 1217 58-4 Hwa Ahm Dong, Yusong, Daejon 1218 Korea 305-732 1219 Phone: +82-42-866-6136 1220 Email: mhkang@icu.ac.kr 1222 Jung Yul Choi 1223 Information and Communications University (ICU) 1224 58-4 Hwa Ahm Dong, Yusong, Daejon 1225 Korea 305-732 1226 Phone: +82-42-866-6208 1227 Email: passjay@icu.ac.kr 1229 Gyu Myung Lee 1230 Information and Communications University (ICU) 1231 58-4 Hwa Ahm Dong, Yusong, Daejon 1232 Korea 305-732 1233 Phone: +82-42-866-6231 1234 Email: gmlee@icu.ac.kr 1236 Jook Uk Um 1237 KT Network Engineering Center 1238 206 Jungja-dong, Bungdang-gu, Sungnam City, Kyonggi-do, 463-711, 1239 Korea 1240 Phone: +82-31-727-6610 1241 Email: jooukum@kt.co.kr 1243 Yong Jae Lee 1244 KT Network Engineering Center 1245 206 Jungja-dong, Bungdang-gu, Sungnam City, Kyonggi-do, 463-711, Korea 1246 Phone: +82-31-727-6651 1247 Email: cruiser@kt.co.kr 1249 Young Wook Cha 1250 Andong National University (ANU) 1251 388 Song-Chon Dong, Andong, Kyungsangbuk-do 1252 Korea 760-749 1253 Phone: +82-54-820-5714 1254 Email: ywcha@andong.ac.kr 1256 Jeong Yun Kim 1257 Electronics and Telecommunications Research Institute (ETRI) 1258 161 KaJong-Dong, Yusong-Gu, Daejeon 1259 Korea 305-309 1260 Phone: +82-42-866-5311 1261 Email: jykim@etri.re.kr 1263 Jonathan Sadler 1264 Tellabs Operations, Inc. 1265 1415 West Diehl Road 1266 Naperville, IL 60563 1267 Phone: +1 630-798-6182 1268 Email: Jonathan.Sadler@tellabs.com 1270 Avri Doria 1271 Div. of Computer Communications 1272 Lulea University of Technology 1273 S-971 87 Lulea 1274 Sweden 1275 Phone: +1 401 663 5024 1276 EMail: avri@acm.org 1278 Full Copyright Statement 1280 Copyright (C) The Internet Society (2002). All Rights Reserved. This 1281 document and translations of it MAY be copied and furnished to others, 1282 and derivative works that comment on or otherwise explain it or 1283 assist in its implementation MAY be prepared, copied, published and 1284 distributed, in whole or in part, without restriction of any kind, 1285 provided that the above copyright notice and this paragraph are 1286 included on all such copies and derivative works. However, this 1287 document itself MAY not be modified in any way, such as by removing 1288 the copyright notice or references to the Internet Society or other 1289 Internet organizations, except as needed for the purpose of 1290 developing Internet standards in which case the procedures for 1291 copyrights defined in the Internet Standards process MUST be 1292 followed, or as required to translate it into languages other than 1293 English. 1295 The limited permissions granted above are perpetual and will not be 1296 revoked by the Internet Society or its successors or assigns. 1298 This document and the information contained herein is provided on an 1299 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1300 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1301 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1302 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1303 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.