GSMP Working Group                                           Avri Doria
Internet Draft                                          Kenneth Sundell
Document: <draft-ietf-gsmp-reqs-00.txt>                    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]