idnits 2.17.1 draft-ietf-gsmp-optical-spec-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: ---------------------------------------------------------------------------- ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 10) being 61 lines 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 are 2 instances of too long lines in the document, the longest one being 2 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 -- 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 (October 2002) is 7863 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 495, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 498, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 501, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 505, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 516, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 520, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 526, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-gsmp-reqs-03 ** 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 (-09) exists of draft-ietf-mpls-generalized-signaling-08 == Outdated reference: A later version (-05) exists of draft-ietf-ipo-framework-02 ** Downref: Normative reference to an Informational draft: draft-ietf-ipo-framework (ref. '5') == Outdated reference: A later version (-02) exists of draft-osu-ipo-mpls-issues-00 -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' == Outdated reference: A later version (-05) exists of draft-ietf-ipo-impairments-02 ** Downref: Normative reference to an Informational draft: draft-ietf-ipo-impairments (ref. '11') == Outdated reference: A later version (-04) exists of draft-ceuppens-mpls-optical-00 -- Possible downref: Normative reference to a draft: ref. '12' ** Downref: Normative reference to an Informational RFC: RFC 3294 (ref. '13') Summary: 12 errors (**), 0 flaws (~~), 17 warnings (==), 8 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-00.txt Min Ho Kang(ICU) 3 Expiration Date: April 2003 Jung Yul Choi(ICU) 4 Gyu Myoung Lee(ICU) 5 Joo Uk Um(KT) 6 October 2002 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 GSMP controller SHOULD control optical label switches and manage optical 34 resources on them. This document describes the extended functions of 35 GSMP for optical switching and explains operational mechanisms to 36 implement them. It SHOULD be referred with [1] for the complete 37 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 Choi at el Expires - April 2003 [Page 1] 48 GSMPv3 for Optical Support October 2002 50 1. Introduction.....................................................3 51 2. Common Definition and Procedures for Optical Support.............3 52 2.1 Labels..........................................................3 53 2.1.1 Label for Wavelength and Fiber................................3 54 2.1.2 Label for Waveband............................................4 55 2.1.3 Label for optical burst ......................................4 56 2.1.4 Label Range...................................................4 57 2.2 Protection and Restoration Capability in GSMP...................4 58 2.2.1 Dedicated and shared recovery mechanisms......................5 59 2.2.2 Revertible and Non-revertible mode............................5 60 2.3 GSMP support for optical switching systems......................6 61 2.3.1 Capability of GSMP for optical burst switching................6 62 3. Connection Management Messages...................................7 63 3.1 General Message Definitions.....................................7 64 3.2 Add Branch Message..............................................7 65 3.3 Move Output Branch Message......................................7 66 3.4 Move Input Branch Message.......................................7 67 4. Reservation Management Messages..................................7 68 5. State and Statistics Messages....................................8 69 5.1 Statistics Messages.............................................8 70 6. Configuration Messages...........................................8 71 6.1 Switch Configuration Message....................................9 72 6.2 Port Configuration Message......................................9 73 6.3 Service Configuration Message...................................9 74 7. Event Messages...................................................9 75 8. Failure Response Codes...........................................10 76 9. Security Consideratons...........................................10 77 References..........................................................10 78 Acknowledgement.....................................................11 79 Author's Addresses..................................................11 80 Full Copyright Statement............................................13 82 1. Introduction 84 This document describes the extended functions and requirements of 85 GSMPv3 for the support of optical switching. GSMPv3 is an asymmetric 86 protocol to control and manage the label switch. The label switches 87 that are used for optical switching are all optical cross-connects 88 (optical-optical-optical), transparent optical cross connects 89 (optical-electrical-optical, frame independent). 91 In order for GSMP to operate between the controller and optical 92 switched and cross connects, optical labels, services for optical 93 switching, and resource abstractions MUST be defined and added to 94 GSMPv3 for Optical Support October 2002 96 GSMP, since the basic optical resources which are used in connection 97 setup are different with them of the legacy networks. 99 One of the main roles of GSMP is to support restoration capabilities 100 of optical switches and the connection. By extending the management 101 messages of GSMP, this function MUST be implemented. 103 For the complete implementation this document MUST be referred with 104 [1]. 106 2. Common Definitions and Procedures for Optical Support. 108 Common definitions and procedures which are not mentioned in this 109 document follow [1]. 111 2.1 Labels 113 Labels are the basic identifier for a connection. In order to setup 114 connections in optical switch, new labels MUST be defined. The newly 115 defined labels identify the entities that are to be switched in the 116 optical switches. GMPLS defines packet switching capable, TDM 117 switching capable, lambdas switching capable, fiber switching capable 118 interfaces, and it introduces the needs of generalized labels to 119 support them [3][4]. So far, GMPLS does not defined the labels to be 120 used for optical switching (label formats and encoding schemes), but 121 GSMP MUST support the all types of label that to be defined in GMPLS. 122 The following lists are the labels to be supported in the optical 123 switching [2][3][4]. 125 - a single fiber in a bundle 126 - a single waveband within a fiber 127 - a single wavelength within a waveband (or a fiber) 128 - an optical burst within a wavelength 130 2.1.1 Labels for Wavelength and Fiber 132 The label indicates a fiber or a wavelength to be used for a 133 connection establishment in optical switching. Value of the label 134 only has significance between two neighbors, and the receiver MAY 135 need to convert the received value into a value that has local 136 significance. 138 2.1.2 Labels for Waveband 140 A Waveband is a set of contiguous wavelengths which can be switched 141 together to a new waveband [3][4]. It MAY be desirable for an optical 142 cross connect to optically switch multiple wavelengths as a unit 143 since it MAY reduce the distortion on the individual wavelengths and 144 MAY allow tighter separation of the individual wavelengths. The 145 Waveband Label is defined to support such a waveband switching. The 146 waveband label can be encoded in three parts; waveband ID, start 147 label, and end label. The start label and the end label represent the 148 GSMPv3 for Optical Support October 2002 150 lowest value wavelength and the highest value wavelengths. 152 2.1.3 Labels for optical burst 154 The label for optical burst represents the label for switching optical 155 burst data in time domain in a wavelength. However, this label is not 156 defined yet. 158 2.1.4 Label Range 160 The basic label range to be used in each port is specified by the 161 Port Configuration or All Port Configuration message. The Label Range 162 message allows the range of labels supported by a specified port to 163 be changed. The controller MUST allocate the label range with 164 consideration of optical characteristics when assigning the labels 165 for a connection because the connection is established per optical 166 burst, wavelength, waveband, and fiber in optical domain. Since the 167 basic label range varies in switches and the labels for the 168 connections can be different due to the optical characteristics, GSMP 169 does not treat them. However, the following lists SHOULD be 170 considered and the available label ranges can be applied in the Label 171 Range message. 173 - When allocating a label for a wavelength, the label SHOULD be 174 allocated for it with consideration of wavelength continuity. For 175 satisfying the requirement of wavelength continuity in a 176 connection, the label SHOULD be allocated to maintain the same 177 wavelength for it. The controller MUST manage the available labels 178 and support the constraint. 180 - The labels to be used for waveband switching MUST be contiguous, 181 because the waveband switching is possible only in the set of 182 contiguous wavelengths. The decision mechanism for the available 183 label range is out of scope of GSMPv3. 185 2.2 Protection and Restoration Capability in GSMP 187 The GSMP controller MUST support the protection and restoration 188 capabilities because the optical switch delivers several Gbps data 189 traffic in a single wavelength. To achieve fast protection and 190 restoration, the optical switch is capable of taking an action 191 independent of the GSMP controller, then it informs the controller 192 after completing the restoration [2]. This differs from the master- 193 slave relationship in GSMP. Therefore, the GSMP port configuration 194 command MUST be extended to allow autonomous protection mechanism. 195 The current GSMP connection management also MUST be extended to 196 support this function. 198 2.2.1 Dedicated and shared recovery mechanisms 200 In the dedicated protection, both working and backup path deliver the 201 traffic simultaneously from an ingress node to an egress node. The 202 GSMPv3 for Optical Support October 2002 204 egress node of the path selects one of them as a working path 205 according to the received signal status from the previous node. Since 206 the backup path also delivers the traffic it MUST be established by 207 using the Add Branch message. When any link in the working path fails, 208 the egress node switches over from the failed working path to the 209 backup path without noticing the GSMP controller automatically. 211 After completing the recovery of the failed path, the switch reports 212 the fact of configuring a new connection to the controller. When the 213 failed original path is repaired the controller determines how to 214 deal with the path according to the revertible or nonrevertible mode. 215 In the revertible mode, the currently used backup path is changed to 216 the repaired original path by using the Move Input Branch message 217 which includes the new port and label of which values are used for 218 the original connection. In the nonrevertible mode, the controller 219 deletes the repaired original working path by using the Delete Branch 220 message, or uses it as a new backup path for the currently used 221 backup path by using the Add Branch message. 223 In 1:N shared protection, N working paths share the one backup path. 224 In a different way of the dedicated protection, the shared path does 225 not deliver any traffic since the controller does not know which 226 working paths will use it. The controller uses the Reservation 227 message to reserve a connection for the backup path. When a link 228 fails among the N working paths, the controller issues the Add Branch 229 message to restore the traffic through the failed working path into 230 the new backup path 232 2.2.2 Revertible and Non-revertible mode 234 In the revertible mode, when the failed working path is repaired, the 235 controller restores the currently used backup path to the original 236 working path. The GSMP controller MUST keep the information for the 237 working path. The controller issues the Move Input/Output Branch 238 messages with the new port and label of which values are that of the 239 working path to restore it. After restoring, the backup path is 240 deleted by using the Delete message or continuously used as a backup 241 purpose. 243 In non-revertible mode, the working path is not restored from the 244 currently used backup path even though it is repaired. The original 245 working path can be used as a new backup path by using the Add Branch 246 message (1+1 dedicated protection), or the Reservation message (1:N 247 shared protection) 249 2.3 GSMP support for optical switching systems 251 GSMP SHOULD control and manage the optical cross-connect systems as 252 label switches. The optical cross-connect (OXC) is a space division 253 switch that can switch an optical data stream on an input port to an 254 output port. 256 GSMPv3 for Optical Support October 2002 258 The OXC system can be consist of switching fabric, 259 multiplexer/demultiplexer, wavelength converter, and optical- 260 electrical/electrical-optical converter. Multiple wavelengths are 261 multiplexed or demultiplexed into a fiber. Multiple fibers belongs to 262 a fiber bundle. A wavelength, a waveband, and a fiber can be used to 263 establish a connection in an optical switch. They SHOULD be 264 recognized at a port in the OXC since they are connection entities. 265 When the OXC has optical-electrical conversion at the input port and 266 electrical-optical conversion at the output port it is called as 267 opaque OXC. Or, when it processes optical data stream all optically 268 it is called as transparent OXC. Wavelength converter SHOULD be used 269 to resolve output port contention when two different connections try 270 to be established in a same output port. Since the wavelength 271 converter can work only within a limited operating range, the limited 272 numbers of wavelengths are used at the output port. It limits the 273 available wavelengths at the output port. 275 In order to control and manage the OXC systems, GSMP SHOULD be 276 located as a subset of functions for it and MUST know the current 277 switch, port and service configuration information. GSMP controller 278 SHOULD identify the connection entities at the OXC and match them 279 with the optical labels. 281 2.3.1 Capability of GSMP for optical burst switching 283 GSMPv3 SHOULD also support data burst switching as a new connection 284 entity in optical domain. As described in [9],[10], connection setup 285 for optical burst includes reserving time on the transport medium for 286 the client. 288 This time is characterized by two parameters: a start time and the 289 duration of data burst. These values MAY define a fast one-way 290 reservation. Upon a request for setup of a burst connection, the GSMP 291 controller MUST perform appropriate Connection Admission Control for 292 the time and duration specified. If the connection is allowed, it 293 MUST signal these parameters to the burst switching device to reserve 294 the exact bandwidth required [9],[10]. The burst switch MUST perform 295 the switching operation autonomously, using the synchronization 296 methods prescribed for the burst network it is operating in. 298 3. Connection Management Messages 300 3.1 General Message Definitions 302 Connection management messages, which are used for establishing, 303 releasing, modifying, and verifying connections across the switch by 304 the controller, can operate in the optical domain, as the same 305 mechanisms. However, it is not possible to process each packet in 306 optical domain so that such a traffic parameter can not be used to 307 specify the connection. Connection management messages also SHOULD 308 support the OXC restoration capabilities. 310 GSMPv3 for Optical Support October 2002 312 3.2 Add Branch Message 314 The Add Branch message is used to setup a connection. Especially, it 315 MUST support restoration capabilities in the optical domain. For 1+1 316 dedicated protection, it is required to make an additional connection 317 as a backup path to protect an original connection against failure. 318 Additional fields are not required in the Add Branch message to 319 support the restoration capabilities since the two connections are 320 used for data traffic and an egress node selects one between them so 321 that they functions same. However, the controller SHOULD know the 322 whole statues of the switch. 324 3.3 Move Output Branch Message 326 The Move Output Branch message is used to change the current output 327 port label to the new output port label for re-establishing the 328 existing connection. It can be used to support restoration 329 capabilities. Since to re-establish output port of a switch at an 330 ingress node is to change a start point of the current connection, it 331 can be used for 1:1 protection or 1:N shared protection where an 332 ingress node begins a connection. Upon a fault occurring, in order to 333 setup a new backup path instead of the failed working path, the new 334 port in upstream node SHOULD be connected to the current connection 335 by using this message. Because, the ingress node also takes 336 responsibility for recovery, as well as the egress node. 338 3.4 Move Input Branch Message 340 The Move Input Branch message is used to change the current input 341 port label to the new input port label for re-establishing the 342 existing connection. It is also used to support restoration 343 capabilities. It is used for the revertible mode that is to move back 344 to the original connection from a backup connection after a recovery 345 completed. The new port/label in this message uses that of the 346 original connection. 348 4. Reservation Management Messages 350 The Reservation Management message that reserves resources for a 351 connection before establishing a connection SHOULD reserve optical 352 resources, such as data burst, wavelengths, a set of wavelengths for 353 waveband switching, and fibers. In order to use the reservation 354 management messages, optical resources which the OXC supports SHOULD 355 be defined. It can be used to support restoration capabilities for 356 reserving backup connections. Especially, 1:N shared protection 357 scheme reserves a spare connection which is reserved for N working 358 connections so that this MUST use the reservation request messages 359 for reserving a backup connection. The reserved connection identified 360 by the reservation ID SHOULD be informed to N working connections. In 361 the reservation request message, the input label and output label of 362 the reserving branch SHOULD be assigned. After a fault occurs, the 363 GSMPv3 for Optical Support October 2002 365 recovery procedure to make a backup connection just follows the 366 ordinary connection setup procedure in [1]. 368 5. State and Statistics Messages 370 The State and Statistics messages can be used to monitor the 371 statistics related to ports and connection for optical transmission. 372 It allows the controller to request the state and statistics of the 373 switch. 375 5.1 Statistics Messages 377 The statistics messages are used to query the performance statistics 378 related to ports and connections for optical transmission. Since the 379 current statistics messages in [1] report the statistics related to 380 traffic states per cells, or frames, the new fields SHOULD be added 381 into the message for querying the optical support. The Port 382 Statistics message requests the statistics for the ports of the 383 switch. The Connection Statistics message allows the controller to 384 report the performances and statistics of the connection itself. The 385 statistics elements to monitor in the OXC are following. 387 - signal degradation 388 - loss of signal 390 As a result of performance analysis through the statistics messages, 391 the new connection can be requested when the controller finds the 392 much degraded performance on the connection. Therefore, the 393 statistics message to detect a fault SHOULD be defined, but the fault 394 detection mechanism is out of scope of this document. 396 6. Configuration Messages 398 The configuration messages allow the controller to discover the 399 capabilities of optical switch. Switch configuration, port 400 configuration, and service configuration messages are defined for 401 these functions. 403 6.1 Switch Configuration Message 405 Since an optical switch MAY be able to provide connection services at 406 multiple transport layers, and not all switches are expected to 407 support the same transport layers, the switch will need to notify the 408 controller of the specific layers it can support. Therefore, the 409 switch configuration message MUST be extended to provide a list of 410 the transport layers for which an optical switch can perform 411 switching. The following lists are the possible switching layers. 413 GSMPv3 for Optical Support October 2002 415 - switching per optical burst 416 - switching per a single wavelength 417 - switching per a waveband 418 - switching per a single fiber 419 - switching per a fiber bundle 421 6.2 Port Configuration Message 423 The port configuration message supplies the controller with the 424 configuration information related to a single port. In the OXC, the 425 new port types SHOULD be defined in GSMP. Port types MUST be added to 426 support the mix of optical signals that can operate over a single 427 fiber. Basically the port can be used per wavelength, per fiber, and 428 per fiber bundle. Moreover, the OXC can have many bays which contain 429 hundreds of shalves which have tens of thousands of port. Therefore, 430 physical bay and shelve identifiers also SHOULD be defined and 431 encoded in port configuration message. The port configuration 432 information that MAY need to be conveyed includes: 434 - available wavelengths per interface 435 - bit rate per wavelength (port) 436 - type of fiber 438 6.3 Service Configuration Message 440 The Service Configuration message requests the optical switch for the 441 configuration information of the supported services. The requested 442 services are identified in the service ID in the Add Branch message 443 or the Reservation message. The service model is defined with traffic 444 parameter, QoS parameter, and traffic control elements in [1], but 445 these parameters can not be used to specify the optical services. 446 Therefore this message SHOULD be modified to support optical services 447 with newly defined capability sets. The services supported at optical 448 switches SHOULD be defined for dealing with optical burst, wavelength, 449 waveband, and fiber connection. 451 7. Event Messages 453 The Event messages allow the switch to inform the controller of 454 certain asynchronous events. The asynchronous events include mainly 455 port states indication. The indication of these asynchronous events 456 related to ports can provide a port failure to the controller and it 457 can initiate a fault recovery mechanism. 459 8. Failure Response Codes 461 This chapter describes the failure and warning states which can occur 462 in setup optical connections. The following lists are the codes that 463 SHOULD be defined and added in the Failure Response messages. These 464 codes MAY be added when the services for optical switching are 465 defined. The code numbers will be assigned in IANA. 467 GSMPv3 for Optical Support October 2002 469 - no available wavelength at a port 470 - no available backup link for protection 471 - waveband connection setup fails 472 - reservation for optical burst fails 474 9. Security Considerations 475 This document does not have any security concerns. The security 476 requirements using this document are described in the referenced 477 documents 479 References 481 [1] Doria, A, Sundell, K, Hellstrand, F, Worster, T, "General Switch 482 Management Protocol V3," RFC 3292, June 2002. 484 [2] Georg Kullgren, et. al., "Requirements For Adding Optical Support 485 To GSMPv3",draft-ietf-gsmp-reqs-03.txt, Sept. 2002 487 [3] Mannie, E., et. al., "Generalized Multi-Protocol Label Switching 488 (GMPLS) Architecture," draft-ietf-ccamp-gmpls-architecture-03.txt, 489 August 2002. 491 [4] Ashwood-Smith, D., et. al., "Generalized MPLS - Signaling 492 Functional Description," Internet Draft draft-ietf-mpls-generalized- 493 signaling-08.txt, April 2002. 495 [5] Rajagopalan, B., et. al., _IP over Optical Networks: A Framework, 496 draft-ietf-ipo-framework-02.txt (work in progress), June 2002. 498 [6] N. Chandhok, et. al., "IP over WDM Networks; A Summary Issue", 499 draft-osu-ipo-mpls-issues-00,txt, July 2000 501 [7] Jin Ho Hahm, Kwang-il Lee, Mark Carson, "Control Mechanisms for 502 Traffic Engineering in Optical Networks", drafh-hahm-te-optical- 503 00.txt, July 2000 505 [8] Daniel Awduche, WYakov Rekhter, "Multiprotocol Lambda Switching: 506 Combining MPLS Traffic Engineering Control with Optical 507 Crossconnects", IEEE Comm. Mag., March 2001 509 [9] C. Qiao, M. Yoo, "Choice, and Feature and Issues in Optical Burst 510 Switching", Optical Net. Mag., vol.1, No.2, Apr.2000, pp.36-44. 512 [10] OBS Ilia Baldine, George N. Rouskas, Harry G. Perros, Dan 513 Stevension, "JumpStart: A Just-in-time Signaling Architecture for WDM 514 Burst-Switching Networks", IEEE Comm. Mag., Fab. 2002. 516 [11] Angela Chiu, John Strans, et. al., "Impairments And Other 517 Constraints On Optical Layer Routing", draft-ietf-ipo-impairments- 518 02.txt, Feb. 2002. 520 [12] Luc Ceuppens, et. al., "Performance Monitoring in Photonic 521 Networks in support of MPL(ambda)S", draft-ceuppens-mpls-optical- 522 00.txt, Jung 2000. 524 GSMPv3 for Optical Support October 2002 526 [13] Doria, A. and K. Sundell, "General Switch Management Protocol 527 Applicability", RFC 3294, June 2002. 529 Acknowledgement 531 This work was supported in part by the Korean Science and Engineering 532 Foundation (KOSEF) through OIRC project 534 Author's Addresses 536 Jun Kyun Choi 537 Information and Communications University (ICU) 538 58-4 Hwa Ahm Dong, Yusong, Daejon 539 Korea 305-732 540 Phone: +82-42-866-6122 541 Email: jkchoi@icu.ac.kr 543 Min Ho Kang 544 Information and Communications University (ICU) 545 58-4 Hwa Ahm Dong, Yusong, Daejon 546 Korea 305-732 547 Phone: +82-42-866-6136 548 Email: mhkang@icu.ac.kr 550 Jung Yul Choi 551 Information and Communications University (ICU) 552 58-4 Hwa Ahm Dong, Yusong, Daejon 553 Korea 305-732 554 Phone: +82-42-866-6208 555 Email: passjay@icu.ac.kr 557 Gyu Myung Lee 558 Information and Communications University (ICU) 559 58-4 Hwa Ahm Dong, Yusong, Daejon 560 Korea 305-732 561 Phone: +82-42-866-6231 562 Email: gmlee@icu.ac.kr 564 Young Wook Cha 565 Andong National University (ANU) 566 388 Song-Chon Dong, Andong, Kyungsangbuk-do 567 Korea 760-749 568 Phone: +82-54-820-5714 569 Email: ywcha@andong.ac.kr 571 Jeong Yun Kim 572 Electronics and Telecommunications Research Institute (ETRI) 573 161 KaJong-Dong, Yusong-Gu, Daejeon 574 GSMPv3 for Optical Support October 2002 576 Korea 305-309 577 Phone: +82-42-866-5311 578 Email: jykim@etri.re.kr 580 Hormuzd Khosravi 581 Intel 582 2111 NE 25th Avenue 583 Hillsboro, OR 97124 USA 584 Phone: +1 503 264 0334 585 Email: hormuzd.m.khosravi@intel.com 587 Georg Kullgren 588 Nortel Networks AB 589 S:t Eriksgatan 115 A 590 P.O. Box 6701 591 SE-113 85 Stockholm Sweden 592 Email: geku@nortelnetworks.com 594 Jonathan Sadler 595 Tellabs Operations, Inc. 596 1415 West Diehl Road 597 Naperville, IL 60563 598 Phone: +1 630-798-6182 599 Email: Jonathan.Sadler@tellabs.com 601 Stephen Shew 602 Nortel Networks 603 PO Box 3511 Station C 604 Ottawa, ON 605 K1Y 4H7 606 Email: sdshew@nortelnetworks.com 608 Kohei Shiomoto 609 Email: Shiomoto.Kohei@lab.ntt.co.jp 611 Atsushi Watanabe 612 Nippon Telegraph and Telephone Corporation 613 807A 1-1 Hikari-no-oka, Yokosuka-shi 614 Kanagawa 239-0847, Japan 615 Email: atsushi@exa.onlab.ntt.co.jp 617 Satoru Okamoto 618 Nippon Telegraph and Telephone Corporation 619 9-11 Midori-cho 3-chome, Musashino-shi 620 Tokyo 180-8585, Japan 621 Email: okamoto@exa.onlab.ntt.co.jp 623 Avri Doria 624 Div. of Computer Communications 625 Lulea University of Technology 626 S-971 87 Lulea 627 Sweden 628 GSMPv3 for Optical Support October 2002 630 Phone: +1 401 663 5024 631 EMail: avri@acm.org 633 Fiffi Hellstrand 634 Nortel Networks AB 635 S:t Eriksgatan 115 A 636 SE-113 85 Stockholm Sweden 637 EMail: fiffi@nortelnetworks.com 639 Kenneth Sundell 640 Nortel Networks AB 641 S:t Eriksgatan 115 A 642 SE-113 85 Stockholm Sweden 643 EMail: ksundell@nortelnetworks.com 645 Tom Worster 646 Phone: +1 617 247 2624 647 EMail: fsb@thefsb.org 649 Full Copyright Statement 651 Copyright (C) The Internet Society (2002). All Rights Reserved. This 652 document and translations of it MAY be copied and furnished to others, 653 and derivative works that comment on or otherwise explain it or 654 assist in its implementation MAY be prepared, copied, published and 655 distributed, in whole or in part, without restriction of any kind, 656 provided that the above copyright notice and this paragraph are 657 included on all such copies and derivative works. However, this 658 document itself MAY not be modified in any way, such as by removing 659 the copyright notice or references to the Internet Society or other 660 Internet organizations, except as needed for the purpose of 661 developing Internet standards in which case the procedures for 662 copyrights defined in the Internet Standards process MUST be 663 followed, or as required to translate it into languages other than 664 English. 666 The limited permissions granted above are perpetual and will not be 667 revoked by the Internet Society or its successors or assigns. 669 This document and the information contained herein is provided on an 670 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 671 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 672 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 673 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 674 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.