GSMP Working Group Avri Doria Internet Draft Kenneth Sundell Document: Stephen Shew Category: WG Draft Nortel Networks Hormunzd Khosravi Intel July 2001 Requirements for adding Optical Switch Support to GSMP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo provides an overview of the requirements on the GSMP protocol for support of optical switching. 1. Overview This draft is intended to describe the required changes to GSMP for support of optical (non-transparent and all optical), SONET/SDH, and spatial switching of IP packets, L2 frames and TDM data. The mix of possible instantiations include GSMP controllers connected to: photonic cross-connects (optical-optical), transparent optical cross connects (optical-electrical-optical, frame independent), opaque cross connects (optical-electrical-optical, SONET/SDH frames), and traditional TDM switches (all electrical). These could form IP based 1 Internet Draft Req. for Optical Support in GSMP July 2001 optical routers, optical label switches, wavelength routers, and dynamic optical cross connects. There are also several different generic models that might be applied to running IP over WDM [1][2][11]. This document defines the requirements for the separation of control functions from data functions in order to provide a more flexible network architecture.[3] In this draft, no position will be taken about the eventual architectural model that will be 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). GSMPv3[6] is well suited for providing the control mechanisms necessary for allowing an IP based controller to direct the activities of an optical switch. In order for GSMP to operate between IP controllers and optical switches and cross connects, support for optical labels and service and resource abstractions must be added to GSMP. 2. Label Types New labels are needed to identify the entities that are to be switched in the optical fabric. These are longer than GSMPv3 labels as they have physical and structural context. As GMPLS[1][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) - PDH labels [12] - OTN G.709 labels - Lambdas - Fibers GSMP MUST include support for all label types as well as for label hierarchies and label lists as defined by GMPLS. Bundles of the above labels SHOULD also be supported (e.g., 5 OC- 3s, contiguous wavebands) 3. Port and Label Management Issues As with routers, it may be useful to recognize bundles of links [13] between optical cross-connects. This goes beyond knowledge of separate independent ports. If so, changes to the port management message MAY be needed to describe ports which are part of a link bundle. Doria et. al. Expires January 2002 [Page 2] Internet Draft Req. for Optical Support in GSMP July 2001 An updated label range message MUST be provided. There MUST also be support of multiplexing (e.g. no multiplexing, SONET, Gigabit Ethernet multiplexing etc). 4. Statistics messages No changes are currently proposed for the statistics messages to support optical switching. 5. Configuration Issues 5.1 Switch Configuration No changes are currently proposed for the switch configuration messages to support optical switching. 5.2 Port Configuration The port configuration message supplies the controller with the configuration information related to a single port. In order to handle the specific port types in an optical switch, extensive additions will need to be made to this command. Port types MUST be added to support the mix of SONET/SDH signals that can operate over a single fiber. Information that MAY need to be conveyed includes[8]: - wavelengths available per interface - bit rate per wavelength - type of fiber Again, it MAY be useful to recognize bundles of links [13] between optical cross-connects. If so, changes to the port configuration message would be needed to describe ports which are part of a link bundle. 5.3 Service Configuration While new capability sets MUST be added to support quality parameters in optical switches, no changes are foreseen to the service configuration message as its role to carry the service information as defined in the applicable service model. The changes related to the service model will be discussed in section 0. 6. Service Model Issues While one assumption of using optical media is that bandwidth is plentiful, it should be expected that traffic engineering will be necessary in any case[3]. GSMP provides the means for each connection, or in this each light trail, to be created with specific quality attributes. Capability to control re-timing and re-shaping MUST be added. Doria et. al. Expires January 2002 [Page 3] Internet Draft Req. for Optical Support in GSMP July 2001 Currently, the default set of service models in GSMP are all based on the services models defined elsewhere, e.g. the Intserv model[5][7], the Diffserv[4] model, ATM QoS models and the Frame relay forum QoS models. A determination needs to be made of the applicable quality models for optical channel trails. These models MUST then be mapped to the GSMP capability set mechanism. 7. Encapsulation issues The working group needs to decide whether a new encapsulation is required. In other words, will all optical switches used in either the MPLS over Optics and the IP over optics applications require that IP be implemented on the control channel connecting the GSMP controller and Optical switch (the GSMP target). If a raw wavelength control connection is to be allowed, a new encapsulation SHOULD be defined. 8. MIB Issues If a new encapsulation is defined, then the encapsulation group SHOULD be updated. No other changes should be required. 9. OXC Transaction Model 9.1 Serial Transactions Many existing OXCs use a command interface which assumes a serial transaction model. That is, a new command cannot be issued or processed until the existing command is completed. Under provisioning control via a network management application, and with non-dynamic path setup, this model has been adequate. Moving to a dynamic path setup capability with a distributed control plane, a parallel transaction model is likely required for performance. This is particularly helpful when the performance of setting up a TDM style connection is much slower than setting up an L2 connection table. If the OXC is not able to support a parallel transaction model, a GSMP controller MUST be informed of this and adopt serial transaction behaviour. 9.2 Bulk Transactions Again due to the time it may take some OXCs to setup TDM connections relative to L2 fabrics (e.g., VC-4/STS-1 SPE fabric in an HOVC/STS switch), support for sending multiple transactions in the same message is a useful optimization. When an OXC receives a bulk message, the individual transactions are acted upon and a single reply is sent. If parallel transactions are not supported, bulk messages can improve performance by reducing transaction overhead. Bulk transactions SHOULD be supported. Doria et. al. Expires January 2002 [Page 4] Internet Draft Req. for Optical Support in GSMP July 2001 10. OXC Restoration Capabilities To achieve fast link protection performance (e.g., 50 ms after failure detection), SONET/SDH and some OXC systems use hardware based protection schemes (e.g., ring protection). Achieving this level of performance solely using a data control plane such as GMPLS is a serious challenge. An alternate approach is to utilize fast restoration capabilities of an OXC with a dynamic control plane. An implication of this hybrid approach is that extensions are needed to GSMP to provision the behaviour of an OXC in anticipation of a link failure. This differs from the strict master-slave relationship in GSMP for Layer 2 switches in that here the OXC is capable of taking an action independent of the GSMP controller and then informing the controller afterwards. 10.1 Non-Reserved Protection Links An example of protection OXC behaviour is that when a link fails, a backup link may be used to protect traffic on. This backup link could be selected from a set of links, none of which are pre- reserved. A backup link could be shared with one or more "working" links which is a form of 1:n shared protection. Specifying the set of possible backup links SHOULD be done as an option to the Add- Branch message. When a backup link is used or the OXC reverts back to the original link, the control plane (i.e., signalling) 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. 10.2 Dedicated Protection Links A more specialized form of restoration called "1+1" defines a (usually node disjoint) protection path in a transport/optical network for a given working path. At the ingress node to the path, the traffic signal is sent simultaneously along both working and protection paths. Under non-failure conditions at the egress node, only the last link of the working path is connected to the client. When any link in the working path fails, traffic on the working path ceases to be received at end of the path. The egress OXC detects this condition and then switches to use the last link of the protection path without the controller having to issue a Move-Input- Branch message. At no time is the ingress node aware which link the egress node is using. Selection of the protection path and all of its links is outside the scope of GSMP. Doria et. al. Expires January 2002 [Page 5] Internet Draft Req. for Optical Support in GSMP July 2001 Specification of the two output branches at the ingress node can be done with the usual Add-Branch semantics. The ingress node protection link is not shared with any other working link. Specification of the two input branches at the egress node should be done when the Add-Branch message is sent. This SHOULD be an option to that message. The egress node protection link is not shared with any other working link. When a protection link is used or the OXC reverts back to the working link, the control plane (i.e., signalling) 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. If an alternate input port is not specified with an original Add- Branch message, it MAY be specified in a subsequent Add-Branch message. In this case, it is useful to include information about existing users of the output port in that Add-Branch message. This helps the OXC immediately learn of the association between the new input port and an existing one. The association is used to enable OXC protection procedures. This capability MUST be added to the add- branch message. 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. 10.3 Protection Triggers Aside from link or equipment failures, there are a variety of maintenance conditions that could cause the backup/protection link(s) to be used. These may include: - Scheduled maintenance of the working link. Here the network operator deliberately takes a link out of service to perform maintenance. - Reconfiguration of fiber/node/network which causes temporary need to use backup links. It may be useful to specify these triggers when the backup/protection links are defined with the Add-Branch message. This depends on how the OXC is implemented to be aware of such triggers. This is for further study. 10.4 Protection Link Capabilities When an OXC has the capability to perform protection switching independently from the OCC, it may be useful for the OCC to be informed of these capabilities at switch and/or port configuration. Applications in the GSMP controller could use this information. For example, signalling clients could define a path protection scheme over multiple GSMP enabled OXCs. This is for further study. Doria et. al. Expires January 2002 [Page 6] Internet Draft Req. for Optical Support in GSMP July 2001 11. Security Considerations The security of GSMP's TCP/IP control channel has been addressed in [10]. Any potential remaining security considerations are not addressed in the current revision of this draft. 12. Acknowledgements The authors would like to thank Dimitri Papadimitriou for his valuable comments on this draft. 13. References [1] Ashwood-Smith, D., et. al., "Generalized MPLS - Signaling Functional Description", Internet Draft draft- ietf-mpls-generalized-signaling-04.txt (work in progress), May 2001. [2] Mannie, E., et. al., _Generalized Multi-Protocol Label Switching (GMPLS) Architecture_, draft-ietf- ccamp-gmpls-architecture-00.txt (work in progress), June 2001 [3] Awduche, D, Rekhter, Y, et. al., "Multi-Protocol Lambda Switching: Combining MPLS Traffic Engineering Control with Optical Crossconnects," draft- awduche-mpls-te-optical-02.txt (work in progress), July, 2000 [4] Blake, S., et. al., _An Architecture for Differentiated Services_, RFC2475, December 1998 [5] Braden, R., _Integrated Services in the Internet Architecture: An Overview_, RFC1633, June 1994 [6] Doria, A, Sundell, K, Hellstrand, F, Worster, T, "General Switch Management Protocol V3," Internet Draft draft-ietf-gsmp-08.txt (work in progress), December 2000 Doria et. al. Expires January 2002 [Page 7] Internet Draft Req. for Optical Support in GSMP July 2001 [7] J. Wroclawski, "Specification of the Controlled-Load Network Element Service," RFC2211, Sep 1997. [8] Rajagopalan, B., et. al., _IP over Optical Networks: A Framework_, draft-many-ip-optical-framework- 02.txt (work in progress), November 2000 [9] Sjostrand, H, et al, Definitions of Managed Objects for the General Switch Management Protocol (GSMP)," Internet-Draft draft-ietf-gsmp-mib-04 (work in progress), December 2000. [10] Worster, T, et al, "GSMP Packet Encapsulations for ATM, Ethernet and TCP," Internet-Draft draft-ietf- gsmp-encaps-03 (work in progress), December 2000. [11] G.ASON _Architecture for the Automatic Switched Optical Network_, Draft v0.5.1, June 2001 [12] Sadler, J., Mack-Crane, B., "Generalized Switch Management Protocol", draft-sadler-gsmp-tdm-labels-00.txt (work in progress), February 2001 [13] Kompella, K., et. al., _Link Bundling in MPLS Traffic Engineering_, draft-kompella-mpls-bundle-05.txt (work in progress), February 2001 14. Author's Addresses Avri Doria Nortel Networks 600 Technology Park Drive Billerica MA 01821 avri@nortelnetworks.com Kenneth Sundell Nortel Networks AB P.O. Box 6701 SE-113 85 Stockholm Sweden ksundell@nortelnetworks.com Stephen Shew Nortel Networks PO Box 3511 Station C Ottawa, ON K1Y 4H7 sdshew@nortelnetworks.com Doria et. al. Expires January 2002 [Page 8] Internet Draft Req. for Optical Support in GSMP July 2001 Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503 264 0334 hormuzd.m.khosravi@intel.com Doria et. al. Expires January 2002 [Page 9] Internet Draft Req. for Optical Support in GSMP July 2001 Full Copyright Statement "Copyright (C) The Internet Society 2001. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Doria et. al. Expires January 2002 [Page 10]