Network Working Group H. Khosravi Request for Comments: 3604 Intel Category: Informational G. Kullgren S. Shew Nortel Networks J. Sadler Tellabs A. Watanabe NTT October 2003 Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3) Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.
AbstractThis memo provides requirements for adding optical switching support to the General Switch Management Protocol (GSMP). It also contains clarifications and suggested changes to the GSMPv3 specification. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 .
traditional TDM switches (all electrical). The resulting systems could form IP based optical routers, optical label switches, wavelength routers, and dynamic optical cross connects. Several different generic models exist defining how to provide control plane functionality in an optical network , , . This document takes no position on which model is most appropriate (e.g., single or multiple routing plane instances). The only assumption is that the ability to separate the control mechanisms from the data switching is as useful for the signaling of optical paths (e.g., GMPLS) as it is for the signaling of L2 paths (e.g., MPLS). Therefore, the requirements contained within are focused only on the separation of control functions from data functions in order to provide a more flexible network architecture. GSMPv3  is well suited for providing the control interface necessary for allowing an IP based controller to direct the activities of an optical switch. In order for GSMP to operate between controllers and optical switches and cross connects, support for optical labels and service and resource abstractions must be added to GSMP. This document also includes changes recommended by implementers that will facilitate easier development of a GSMP implementation. These changes consist of rearranging PDU formats, clarification of flags, transaction identifiers, and response codes. 2],  has had very similar requirements for label formats, alignment with GMPLS is proposed. This includes support for: - Digital Carrier Hierarchy (e.g., DS-1, E1) - SONET and SDH Hierarchy (e.g., OC-3, STM-1, VT1.5, VC-12) - Plesiochronous Data Hierarchy (PDH) labels  - OTN G.709 labels - Lambdas - Fibers
GSMP MUST include support for all label types list above, as well as for label hierarchies and label lists as defined by GMPLS. Therefore, the ability to perform operations on groups of the above labels MUST also be supported (e.g., 5 OC-3s, contiguous wavebands).
7]: - wavelengths available per interface - bit rate per wavelength - type of fiber
The Slot/Port Location Identifier MUST be extended to encode Bay/Shelf/Slot/Port. 8]), is very similar to a port. Therefore, when partitioning is done on a transport layer signal basis, the partition that is the user of the access point MUST have a port that associated with the access point. Labels will then be used in the to describe the subordinate signals. 5]. GSMP provides the means for each connection to be created with specific attributes. Therefore, service parameters will need to be defined for each of the Different Optical technologies. 9], , the Diffserv 
model, ATM QoS models and the Frame relay forum QoS models. A determination needs to be made of the applicable service models for optical channel trails. These models MUST then be mapped to the GSMP capability set mechanism. RFC 3293 Ethernet and ATM cases. It is in scope to perform risk analysis and describe if mechanisms for link-level security mitigate the risk.
When a backup link is used or the OXC reverts back to the original link, the control plane (i.e., signaling) may need to know about the new path state in order to notify the operator, or take some other OAM action (e.g., billing, SLA monitoring). An additional GSMP message to inform the controller SHOULD be added to do this.
Similar contextual information is needed for a Delete-Branch message so that the OXC can determine if a path becomes unprotected. This capability MUST be added to the Delete-branch message.
12], , and , part of burst switching connection setup includes reserving time on the transport medium for the client. This time is characterized by two parameters: a start time and the duration. These values MAY define a one-time reservation or a repeating reservation. Upon a request for setup of a burst connection, the GSMP controller MUST perform appropriate Connection Admission Control for the time and duration specified and, if the connection is allowed, MUST signal these parameters to the burst switching device to reserve the exact bandwidth required , . The burst switch MUST perform the switching operation autonomously, using the synchronization methods prescribed for the burst network it is operating in. 5] describes the common fields present in all GSMP messages except for the Adjacency protocol.
5] does not distinguish between replies from a request with "AckAll" and "NoSuccessAck". It also does not provide any information about how to handle replies where the Transaction ID doesn't match a Transaction ID from a previously sent request. If multiple controllers are connected to a single switch and the switch sends an event message with "ReturnReceipt" set to all of them, there is no way for the switch to identify which controller the receipt is coming from. The "ReturnReceipt" value should not be permitted for Events. 5] defines a Window size to be used by the controller when sending messages to the switch. It is not stated if this window should apply to all messages or only to messages that will always generate a reply. If messages that may not generate a reply should be counted against the window a time-out period when they are to be removed from the window should be defined. It is not defined if the window should be cleared when the adjacency is lost and later recovered.
15]. Any potential remaining security considerations are not addressed in this requirements document.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Berger, L., Ed., "Generalized MPLS - Signaling Functional Description", RFC 3471, January 2003.  Mannie, E., et al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", Work in Progress, May 2003.
 ITU-T Recommendation, "Architecture for the Automatically Switched Optical Network (ASON)", G.8080/Y.1304, January 2003  Doria, A., Sundell, K., Hellstrand, F. and T. Worster, "General Switch Management Protocol V3", RFC 3292, June 2002.  Sadler, J., Mack-Crane, B., "TDM Labels for GSMP", Work in Progress, February 2001.  Rajagopalan, B., et al., "IP over Optical Networks: A Framework", Work in Progress, September 2003.  ITU-T Recommendation, "Generic functional architecture of transport networks", G.805, March 2000.  Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: An Overview", RFC 1633, June 1994.  Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, _"An Architecture for Differentiated Services", RFC 2475, December 1998.  C. Qiao, M. Yoo, "Choice, and Feature and Issues in Optical Burst Switching", Optical Net. Mag., vol.1, No.2, Apr.2000, pp.36-44.  Ilia Baldine, George N. Rouskas, Harry G. Perros, Dan Stevension, "JumpStart: A Just-in-time Signaling Architecture for WDM Burst-Switching Networks", IEEE Comm. Mag., Fab. 2002.  Sanjeev Verma, et al. "Optical burst switching: a viable solution for terabit IP backbone", IEEE network, pp. 48-53, Nov/Dec 2000.  Worster, T., Doria, A. and J. Buerkle, "GSMP Packet Encapsulations for ATM, Ethernet and TCP", RFC 3293, June 2002.
Atsushi Watanabe Nippon Telegraph and Telephone Corporation 807A 1-1 Hikari-no-oka, Yokosuka-shi Kanagawa 239-0847, Japan EMail: email@example.com Satoru Okamoto Nippon Telegraph and Telephone Corporation 9-11 Midori-cho 3-chome, Musashino-shi Tokyo 180-8585, Japan EMail: firstname.lastname@example.org
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.