idnits 2.17.1 draft-ietf-gsmp-reqs-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 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 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: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 56 looks like a reference -- Missing reference section? '2' on line 104 looks like a reference -- Missing reference section? '3' on line 104 looks like a reference -- Missing reference section? '4' on line 71 looks like a reference -- Missing reference section? '5' on line 517 looks like a reference -- Missing reference section? '6' on line 109 looks like a reference -- Missing reference section? '7' on line 162 looks like a reference -- Missing reference section? '8' on line 218 looks like a reference -- Missing reference section? '9' on line 255 looks like a reference -- Missing reference section? '10' on line 255 looks like a reference -- Missing reference section? '11' on line 255 looks like a reference -- Missing reference section? '12' on line 454 looks like a reference -- Missing reference section? '13' on line 442 looks like a reference -- Missing reference section? '14' on line 454 looks like a reference -- Missing reference section? '15' on line 556 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 0 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 General Switch Management Protocol (gsmp) Hormuzd Khosravi 3 Internet Draft Intel 4 Document: draft-ietf-gsmp-reqs-06.txt 5 Category: Informational Georg Kullgren 6 Stephen Shew 7 Expiration Date: September 2003 Nortel Networks 9 Jonathan Sadler 10 Tellabs 12 Atsushi Watanabe 13 NTT 15 March 2003 17 Requirements For Adding Optical Support To GSMPv3 19 draft-ietf-gsmp-reqs-06.txt 21 Status of this Memo 23 This document is an Internet-Draft and is subject to all provisions 24 of Section 10 of RFC2026 except that the right to produce derivative 25 works is not granted. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Abstract 44 This memo provides requirements for adding of optical switching 45 support to the General Switch Management protocol (GSMP). It also 46 contains clarifications and suggested changes to the GSMP v3 47 specification. 49 draft-ietf-gsmp-reqs-06.txt September 2003 51 Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 55 this document are to be interpreted as described in RFC-2119 [1]. 57 1. Overview 59 This document details the changes to GSMP necessary for the support 60 of optical (non-transparent and all optical), SONET/SDH, and spatial 61 switching of IP packets, Layer 2 (L2) frames and TDM data. When 62 implemented, GSMP controllers will then be able to control: photonic 63 cross-connects (optical-optical), transparent optical cross connects 64 (optical-electrical-optical, frame independent), opaque cross 65 connects (optical-electrical-optical, SONET/SDH frames), and 66 traditional TDM switches (all electrical). The resulting systems 67 could form IP based optical routers, optical label switches, 68 wavelength routers, and dynamic optical cross connects. 70 Several different generic models exist defining how to provide 71 control plane functionality in an optical network [2][3][4]. 72 This document takes no position on which model is most appropriate 73 (e.g., single or multiple routing plane instances). The only 74 assumption is that the ability to separate the control mechanisms 75 from the data switching is as useful for the signaling of optical 76 paths (e.g., GMPLS) as it is for the signaling of L2 paths (e.g., 77 MPLS). Therefore, the requirements contained within are focused only 78 on the separation of control functions from data functions in order 79 to provide a more flexible network architecture. 81 GSMPv3[5] is well suited for providing the control interface 82 necessary for allowing an IP based controller to direct the 83 activities of an optical switch. In order for GSMP to operate 84 between controllers and optical switches and cross connects, support 85 for optical labels and service and resource abstractions must be 86 added to GSMP. 88 This document also includes changes recommended by implementers that 89 will facilitate easier development of a GSMP implementation. These 90 changes consist of rearranging PDU formats, clarification of flags, 91 transaction identifiers, and response codes. 93 2. Requirements for Optical Support 95 2.1. Label 97 2.1.1. Label Types 99 New labels are needed to identify the entities that are to be 100 switched in the optical fabric. These are longer than the labels 101 defined in GSMPv3 as they have physical and structural context. As 102 draft-ietf-gsmp-reqs-06.txt September 2003 104 GMPLS[2][3] has had very similar requirements for label formats, 105 alignment with GMPLS is proposed. This includes support for: 107 - Digital Carrier Hierarchy (e.g., DS-1, E1) 108 - SONET and SDH Hierarchy (e.g., OC-3, STM-1, VT1.5, VC-12) 109 - Plesiochronous Data Hierarchy (PDH) labels [6] 110 - OTN G.709 labels 111 - Lambdas 112 - Fibers 114 GSMP MUST include support for all label types list above, as well as 115 for label hierarchies and label lists as defined by GMPLS. Therefore 116 the ability to perform operations on groups of the above labels MUST 117 also be supported (e.g., 5 OC-3s, contiguous wavebands) 119 2.1.2. Label Management Issues 121 An updated label range message MUST be provided. There MUST also be 122 support of multiplexing (e.g. no multiplexing, SONET, Gigabit 123 Ethernet multiplexing etc). 125 2.2. Statistics messages 127 Optical switches have a number of different statistics which are not 128 in common with ATM, or Frame Relay switches. Consequently, the 129 statistics messages SHOULD be updated to report Performance 130 Monitoring statistics defined for all new optical transport 131 technologies added to GSMP. 133 2.3. Configuration Issues 135 2.3.1. Switch Configuration 137 2.3.1.1. Layer Switching Identification 139 Since an Optical Switch may be able to provide connection services 140 at multiple transport layers (i.e. STS-3c, STS-1, VT-1.5, DS3, DS1), 141 and not all switches are expected to support the same transport 142 layers, the switch will need to notify the controller of the 143 specific layers it can support. 145 Therefore, the Switch Configuration message MUST be extended to 146 provide a list of the transport layers for which an optical switch 147 can perform switching. 149 draft-ietf-gsmp-reqs-06.txt September 2003 151 2.3.2. Port Configuration 153 The port configuration message supplies the controller with the 154 configuration information related to a single port. Consequently, 155 extensive additions will need to be made to this command. 157 2.3.2.1. Port Type extensions 159 Port types MUST be added to support the mix of optical signals that 160 can operate over a single fiber. 162 The port information that MAY need to be conveyed includes [7]: 164 - wavelengths available per interface 165 - bit rate per wavelength 166 - type of fiber 168 2.3.2.2. Supported Signal Type extensions 170 Since a port on an optical switch may support signals at multiple 171 transport layers, it is necessary to understand the signals 172 supported, as well as the possible ways that one signal can be 173 transported within another. 175 For OTN, SONET/SDH and PDH optical switches, the Port configuration 176 message MUST be extended to detail the different transport layer 177 signals that are supported by a port. Furthermore, this extension 178 MUST detail which signals may be transported by another signal. 180 This mechanism MUST also provide information about optional 181 capabilities (such as virtual concatenation and arbitrary 182 concatenation for SONET/SDH) available on a port. 184 2.3.2.3. Trace Mechanism support Identification 186 A number of transport layer signals include overhead channels that 187 can be used to identify the source of a signal. Since they are 188 embedded in the signal, only the network element has access to the 189 signals. However, not all network elements have the capability to 190 set or read the messages in these channels on every port. 191 Consequently, this port attribute needs to be reported to the 192 controller. 194 The Port Configuration message MUST be extended to report which 195 trace mechanisms are supported by a port. 197 draft-ietf-gsmp-reqs-06.txt September 2003 199 2.3.2.4. Port Location Identification 201 Since contemporary Optical switches have the ability to support tens 202 of thousands of ports in hundreds of shelves located in as 203 potentially as many bays, the current "Slot/Port" location 204 identifier is inadequate. 206 The Slot/Port Location Identifier MUST be extended to encode 207 Bay/Shelf/Slot/Port. 209 2.3.2.5. Port-related Partitioning Extensions 211 Partitioning can be done for any resource that exists in the network 212 element. The GSMP partitioning draft currently defines ports and 213 switching resources as partitionable resources. Since optical 214 switches may support multiple transport network layers, an 215 additional resource type is introduced: the transport layer signal. 217 The point where a transport layer signal is inserted into a lower 218 layer signal (called an "access point" by the ITU [8]), is very 219 similar to a port. Therefore, when partitioning is done on a 220 transport layer signal basis, the partition that is the user of the 221 access point MUST have a port that associated with the access point. 222 Labels will then be used in the to describe the subordinate signals. 224 2.3.3. Service Configuration 226 While new capability sets MUST be added to support quality 227 parameters in optical switches, no changes are foreseen to the 228 service configuration message as its role to carry the service 229 information as defined in the applicable service model. 231 2.4. Service Model Issues 233 While one assumption of using optical media is that bandwidth is 234 plentiful, it should be expected that traffic engineering will be 235 necessary in any case[5]. GSMP provides the means for each 236 connection to be created with specific attributes. Therefore, 237 service parameters will need to be defined for each of the Different 238 Optical technologies. 240 2.4.1 Transparent Optical 242 Capability to control re-timing and re-shaping on a per port level 243 MUST be added. 245 draft-ietf-gsmp-reqs-06.txt September 2003 247 2.4.2 SONET/SDH and OTN 249 The capability to control the adaptation parameters used when a 250 transport signal is inserted into another transport signal MUST be 251 added. These parameters SHOULD be modifiable at times other than 252 adding a branch so that functions such as Tandem Connection 253 Monitoring can be configured. Currently, the default set of service 254 models in GSMP are all based on the services models defined 255 elsewhere, e.g. the Intserv model[9][10], the Diffserv[11] model, 256 ATM QoS models and the Frame relay forum QoS models. A determination 257 needs to be made of the applicable service models for optical 258 channel trails. These models MUST then be mapped to the GSMP 259 capability set mechanism. 261 2.5. Encapsulation issues 263 The working group needs to decide whether a new encapsulation is 264 required. In other words, will all optical switches used in either 265 the MPLS over Optics and the IP over optics applications require 266 that IP be implemented on the control channel connecting the GSMP 267 controller and Optical switch (the GSMP target). 269 A new encapsulation SHOULD be defined allowing the use of a non-IP 270 raw wavelength control connection. 272 Likewise, a new encapsulation SHOULD be defined allowing GSMP to be 273 used in legacy DCN environments that use OSI CLNP. 275 2.6. MIB Issues 277 If a new encapsulation is defined, then the encapsulation group 278 SHOULD be updated. No other changes should be required. 280 2.7. OXC Transaction Model 282 2.7.1 Serial Transactions 284 Many existing OXCs use a command interface which assumes a serial 285 transaction model. That is, a new command cannot be issued or 286 processed until the existing command is completed. Under 287 provisioning control via a network management application, and with 288 non-dynamic path setup, this model has been adequate. 290 Moving to a dynamic path setup capability with a distributed control 291 plane, a parallel transaction model is likely required for 292 performance. This is particularly helpful when the performance of 293 setting up a TDM style connection is much slower than setting up an 294 L2 connection table. If the OXC is not able to support a parallel 295 transaction model, a GSMP controller MUST be informed of this and 296 adopt serial transaction behavior. 298 draft-ietf-gsmp-reqs-06.txt September 2003 300 2.7.2. Bulk Transactions 302 Again due to the time it may take some OXCs to setup TDM connections 303 relative to L2 fabrics (e.g., VC-4/STS-1 SPE fabric in an HOVC/STS 304 switch), support for sending multiple transactions in the same 305 message is a useful optimization. When an OXC receives a bulk 306 message, the individual transactions are acted upon and a single 307 reply is sent. If parallel transactions are not supported, bulk 308 messages can improve performance by reducing transaction overhead. 309 Bulk transactions SHOULD be supported. 311 2.8. OXC Restoration Capabilities 313 To achieve fast link protection performance (e.g., 50 ms after 314 failure detection), SONET/SDH and some OXC systems use hardware 315 based protection schemes (e.g., ring protection). Achieving this 316 level of performance solely using a data control plane such as GMPLS 317 is a serious challenge. An alternate approach is to utilize fast 318 restoration capabilities of an OXC with a dynamic control plane. An 319 implication of this hybrid approach is that extensions are needed to 320 GSMP to provision the behavior of an OXC in anticipation of a link 321 failure. 323 This differs from the strict master-slave relationship in GSMP for 324 Layer 2 switches in that here the OXC is capable of taking an action 325 independent of the GSMP controller and then informing the controller 326 afterwards. Consequently, the GSMP port configuration command MUST 327 be extended to allow autonomous protection behaviors to be 328 provisioned into the Network Element. 330 Furthermore, the controller MUST be able to provide the parameters 331 for when reversion from a backup link to the original link is 332 allowed. This may take the form of hold-off timers, BER parameters, 333 or the requirement for controller directed reversion. 335 2.8.1. Non-Reserved Protection Links 337 An example of protection OXC behavior is that when a link fails, a 338 backup link may be used to protect traffic on. This backup link 339 could be selected from a set of links, none of which are pre- 340 reserved. A backup link could be shared with one or more "working" 341 links which is a form of 1:n shared protection. Specifying the set 342 of possible backup links SHOULD be done as an option to the Add- 343 Branch message. 345 When a backup link is used or the OXC reverts back to the original 346 link, the control plane (i.e., signaling) may need to know about the 347 new path state in order to notify the operator, or take some other 348 draft-ietf-gsmp-reqs-06.txt September 2003 350 OAM action (e.g., billing, SLA monitoring). An additional GSMP 351 message to inform the controller SHOULD be added to do this. 353 2.8.2. Dedicated Protection Links 355 A more specialized form of restoration called "1+1" defines a 356 (usually node disjoint) protection path in a transport/optical 357 network for a given working path. At the ingress node to the path, 358 the traffic signal is sent simultaneously along both working and 359 protection paths. Under non-failure conditions at the egress node, 360 only the last link of the working path is connected to the client. 361 When any link in the working path fails, traffic on the working path 362 ceases to be received at end of the path. The egress OXC detects 363 this condition and then switches to use the last link of the 364 protection path without the controller having to issue a Move-Input- 365 Branch message. At no time is the ingress node aware which link the 366 egress node is using. Selection of the protection path and all of 367 its links is outside the scope of GSMP. 369 Specification of the two output branches at the ingress node can be 370 done with the usual Add-Branch semantics. The ingress node 371 protection link is not shared with any other working link. 373 Specification of the two input branches at the egress node should be 374 done when the Add-Branch message is sent. This SHOULD be an option 375 to that message. The egress node protection link is not shared with 376 any other working link. 378 When a protection link is used or the OXC reverts back to the 379 working link, the control plane (i.e., signaling) may need to know 380 about the new path state in order to notify the operator, or take 381 some other OAM action (e.g., billing, SLA monitoring). An 382 additional GSMP message to inform the controller SHOULD be added to 383 do this. 385 If an alternate input port is not specified with an original Add- 386 Branch message, it MAY be specified in a subsequent Add-Branch 387 message. In this case, it is useful to include information about 388 existing users of the output port in that Add-Branch message. This 389 helps the OXC immediately learn of the association between the new 390 input port and an existing one. The association is used to enable 391 OXC protection procedures. This capability MUST be added to the add- 392 branch message. 394 Similar contextual information is needed for a Delete-Branch message 395 so that the OXC can determine if a path becomes unprotected. This 396 capability MUST be added to the Delete-branch message. 398 draft-ietf-gsmp-reqs-06.txt September 2003 400 2.8.3. Protection Triggers 402 Aside from link or equipment failures, there are a variety of 403 maintenance conditions that could cause the backup/protection 404 link(s) to be used. These may include: 406 - Scheduled maintenance of the working link. Here the network 407 operator deliberately takes a link out of service to perform 408 maintenance. 409 - Reconfiguration of fiber/node/network which causes temporary need 410 to use backup links. 412 It may be useful to specify these triggers when the 413 backup/protection links are defined with the Add-Branch message. 414 This depends on how the OXC is implemented to be aware of such 415 triggers. This is for further study. 417 2.8.4. Protection Link Capabilities 419 When an OXC has the capability to perform protection switching 420 independently from the Optical Call Controller (OCC), it may be 421 useful for the OCC to be informed of these capabilities at switch 422 and/or port configuration. Applications in the GSMP controller 423 could use this information. For example, signaling clients could 424 define a path protection scheme over multiple GSMP enabled OXCs. 425 This is for further study. 427 2.9. Controller directed restoration 429 Bi-directional Connection Replacement 431 Connections in the transport network are inherently point-to-point 432 bi-directional. Unfortunately, GSMPv3 currently does not allow for 433 the B and R flags to be set on an add branch message. This means 434 that it is not possible to do an atomic replacement of a bi- 435 directional connection -- an action that is desirable for controller 436 directed restoration. Consequently, the protocol MUST be changed to 437 allow these flags to be used at the same time. 439 2.10 Support for optical burst switching 441 GSMP for Optical Switching should also support optical burst 442 switching. As described in [12], [13], and [14], part of burst 443 switching connection setup includes reserving time on the transport 444 medium for the client. 446 This time is characterized by two parameters: a start time and the 447 duration. These values MAY define a one-time reservation or a 448 repeating reservation. Upon a request for setup of a burst 449 connection, the GSMP controller MUST perform appropriate Connection 450 draft-ietf-gsmp-reqs-06.txt September 2003 452 Admission Control for the time and duration specified and, if the 453 connection is allowed, MUST signal these parameters to the burst 454 switching device to reserve the exact bandwidth required [12], [14]. 455 The burst switch MUST perform the switching operation autonomously, 456 using the synchronization methods prescribed for the burst network 457 it is operating in. 459 3. Requirements from Implementers 461 This section describes requirements to GSMP v3 based on some 462 implementation experience. They address areas of ambiguity, missing 463 semantics, and configuration recommendations. 465 3.1. GSMP Packet Format 467 The Basic GSMP Message Format in chapter 3.1.1 in [5] describes the 468 common fields present in all GSMP messages except for the Adjacency 469 protocol. 471 3.1.1 Message segmentation 473 If a message exceeds the MTU of the link layer it has to be 474 segmented. This was originally done with the "More" value in the 475 Result field. The addition of the I flag and the SubMessage 476 Number to the header has made the "More" value obsolete. 478 The I flag and SubMessage numbers should be used in all messages 479 that can be segmented. 481 3.1.1.1 SubMessage Number and I flag 483 It should be specified if the SubMessage Number start on 0 or 1 in a 484 segmented message and what value the I flag should have in an 485 message that is not segmented. 487 3.1.1.2 Message Length 489 Clarification of what value should be used in the Length field for 490 segmented messages. Specifically, does the Length field contain the 491 total length of the message or the length of the current segment. 493 3.1.1.3. Message Segmentation example 495 To avoid all ambiguity an example of message segmentation should be 496 provided. 498 draft-ietf-gsmp-reqs-06.txt September 2003 500 3.1.2. Transaction Identifier 502 The Transaction Identifier in [5] does not distinguish between 503 replies from a request with "AckAll" and "NoSuccessAck". It also 504 does not provide any information about how to handle replies where 505 the Transaction ID doesn't match a Transaction ID from a previously 506 sent request. 508 If multiple controllers are connected to a single switch and the 509 switch sends an event message with "ReturnReceipt" set to all of 510 them, there is no way for the switch to identify which controller 511 the receipt is coming from. 513 The "ReturnReceipt" value should not be permitted for Events. 515 3.2. Window Size 517 The Switch Configuration Message defined in chapter 8.1 in [5] 518 defines a Window size to be used by the controller when sending 519 messages to the switch. It is not stated if this window should 520 apply to all messages or only to messages that will always generate 521 a reply. 523 If messages that may not generate a reply should be counted against 524 the window a time-out period when they are to be removed from the 525 window should be defined. 527 It is not defined if the window should be cleared when the adjacency 528 is lost and later recovered. 530 3.3. Retransmission 532 A retransmission policy should be used if no reply is received for a 533 message with "AckAll" set. 535 3.4. Delete Branches Message 537 The "Delete Branch Element" has a 4 bit Error field that should be 538 redefined to match the size of the "Failure Response Codes". 540 3.5. Adjacency 542 The chapter about how to handle a new adjacency and re-established 543 adjacencies should be clarified. 545 draft-ietf-gsmp-reqs-06.txt September 2003 547 3.5.1. Loss of Synchronization 549 The switch must not reset the connection states if another adjacency 550 has already been established since this would destroy an already 551 valid state. 553 4. Security Considerations 555 The security of GSMP's TCP/IP control channel has been addressed in 556 [15]. Any potential remaining security considerations are not 557 addressed in this requirements document. 559 5. Acknowledgements 561 The list of authors provided with this document is a reduction of 562 the original list. Currently listed authors wish to acknowledge that 563 a substantial amount was also contributed to this work by: Avri 564 Doria and Kenneth Sundell 566 The authors would like to acknowledge the careful review and 567 comments of Dimitri Papadimitriou, Torbjorn Hedqvist, Satoru 568 Okamoto, and Kohei Shiomoto. 570 6. Informative References 572 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement 573 Levels", BCP 14, RFC 2119, March 1997. 575 2 Ashwood-Smith, D., et. al., "Generalized MPLS - Signaling 576 Functional Description," RFC 3471, August 2002. 578 3 Mannie, E., et. al., "Generalized Multi-Protocol Label Switching 579 (GMPLS) Architecture," draft-ietf-ccamp-gmpls-architecture-03.txt 580 (work in progress), August 2002. 582 4 International Telecommunications Union, "Architecture for the 583 Automatic Switched Optical Network," G.8080, October 2001. 585 5 Doria, A, Sundell, K, Hellstrand, F, Worster, T, "General 586 Switch Management Protocol V3," RFC 3292, June 2002. 588 6 Sadler, J., Mack-Crane, B., "TDM Labels for GSMP," draft-sadler- 589 gsmp-tdm-labels-00.txt (work in progress), February 2001. 591 7 Rajagopalan, B., et. al., _IP over Optical Networks: A Framework, 592 draft-ietf-ipo-framework-02.txt (work in progress), June 2002. 594 8 International Telecommunications Union, "Generic functional 595 architecture of transport networks", G.805, March 2000. 597 draft-ietf-gsmp-reqs-06.txt September 2003 599 9 Braden, R., "Integrated Services in the Internet Architecture: An 600 Overview," RFC1633, June 1994. 602 10 J. Wroclawski, "Specification of the Controlled-Load Network 603 Element Service," RFC2211, Sep 1997. 605 11 Blake, S., et. al., _"An Architecture for Differentiated 606 Services," RFC2475, December 1998. 608 12 C. Qiao, M. Yoo, "Choice, and Feature and Issues in Optical Burst 609 Switching", Optical Net. Mag., vol.1, No.2, Apr.2000, pp.36-44. 611 13 Ilia Baldine, George N. Rouskas, Harry G. Perros, Dan Stevension, 612 "JumpStart: A Just-in-time Signaling Architecture for WDM Burst- 613 Switching Networks", IEEE Comm. Mag., Fab. 2002. 615 14 Sanjeev Verma, et al. "Optical burst switching: a viable solution 616 for terabit IP backbone", IEEE network, pp. 48-53, Nov/Dec 2000. 618 15 Worster, T, et. al., "GSMP Packet Encapsulations for ATM, 619 Ethernet and TCP," RFC 3293, June 2002. 621 7. Author's Addresses 623 Hormuzd Khosravi 624 Intel 625 2111 NE 25th Avenue 626 Hillsboro, OR 97124 USA 627 Phone: +1 503 264 0334 628 Email: hormuzd.m.khosravi@intel.com 630 Georg Kullgren 631 Nortel Networks AB 632 S:t Eriksgatan 115 A 633 P.O. Box 6701 634 SE-113 85 Stockholm Sweden 635 Email: geku@nortelnetworks.com 637 Jonathan Sadler 638 Tellabs Operations, Inc. 639 1415 West Diehl Road 640 Naperville, IL 60563 641 Phone: +1 630-798-6182 642 Email: Jonathan.Sadler@tellabs.com 644 Stephen Shew 645 Nortel Networks 646 PO Box 3511 Station C 647 Ottawa, ON 648 K1Y 4H7 649 Email: sdshew@nortelnetworks.com 650 draft-ietf-gsmp-reqs-06.txt September 2003 652 Kohei Shiomoto 653 Email: Shiomoto.Kohei@lab.ntt.co.jp 655 Atsushi Watanabe 656 Nippon Telegraph and Telephone Corporation 657 807A 1-1 Hikari-no-oka, Yokosuka-shi 658 Kanagawa 239-0847, Japan 659 Email: atsushi@exa.onlab.ntt.co.jp 661 Satoru Okamoto 662 Nippon Telegraph and Telephone Corporation 663 9-11 Midori-cho 3-chome, Musashino-shi 664 Tokyo 180-8585, Japan 665 Email: okamoto@exa.onlab.ntt.co.jp 666 draft-ietf-gsmp-reqs-06.txt September 2003 668 Full Copyright Statement 670 "Copyright (C) The Internet Society (date). All Rights Reserved. 671 This document and translations of it may be copied and furnished to 672 others, and derivative works that comment on or otherwise explain it 673 or assist in its implementation may be prepared, copied, published 674 and distributed, in whole or in part, without restriction of any 675 kind, provided that the above copyright notice and this paragraph 676 are included on all such copies and derivative works. However, this 677 document itself may not be modified in any way, such as by removing 678 the copyright notice or references to the Internet Society or other 679 Internet organizations, except as needed for the purpose of 680 developing Internet standards in which case the procedures for 681 copyrights defined in the Internet Standards process must be 682 followed, or as required to translate it into languages other than 683 English. The limited permissions granted above are perpetual and 684 will not be revoked by the Internet Society or its successors or 685 assigns. 687 This document and the information contained herein is provided on an 688 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 689 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 690 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 691 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 692 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.