Subject: [GSMP] draft-ietf-gsmp-reqs-02.txt (resend: formating problems fixed)

From: Jonathan Sadler <[email-masked]>
Date: Mon, 01 Jul 2002 07:35:16 -0500

(Some formating problems existed in the previous message sent.  Please
disregard it, and use the attachment to this message instead.)

A new version of the optical requirements draft has been produced by the
design team.

Please review and provide comments to the GSMP list ([email-masked]).

Thank you!

Jonathan Sadler

Generalized Switch Management Protocol (gsmp)            Georg Kullgren
Internet Draft                                              Steven Shew
Document: draft-ietf-gsmp-reqs-02.txt                   Nortel Networks
Category: Standards Track
                                                       Hormuzd Khosravi
Expiration Date: December 2002                                    Intel

                                                        Jonathan Sadler
                                                                Tellabs

                                                         Satoru Okamoto
                                                         Kohei Shiomoto
                                                       Atsushi Watanabe
                                                                    NTT

                                                              June 2002

           Requirements For Adding Optical Support To GSMPv3

                      draft-ietf-gsmp-reqs-02.txt

1. Status of this Memo

   This document is an Internet-Draft and is subject to 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/1id-abstracts.html
   The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html

2. Abstract

   This memo provides an overview of additional requirements on the
   GSMP protocol.

3. Changes

   Merged Sections 2 and 4.

Kullgren, et. al.        GSMP WG - June 2002                        1
                 draft-ietf-gsmp-reqs-02.txt     December 2002

   Moved Link Bundling out of GSMP scope as links are network in scope,
   and not node in scope.

   Where appropriate, changed text that was specific to transparent
   optical switching generic so it also applies to SONET/SDH switching.

   Updated references to current CCAMP Drafts/GSMP RFCs.

   Took out references that were not referred to by the base text.

4. Table of Contents

5. Overview

   This document details the changes to GSMP necessary for the support
   of optical (non-transparent and all optical), SONET/SDH, and spatial
   switching of IP packets, L2 frames and TDM data. When implemented,
   GSMP controllers will then be able to control: 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). 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 [1][2][3].
   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[4] 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.

6. Requirements for Optical Support

6.1. Label

6.1.1. Label Types

   New labels are needed to identify the entities that are to be
   switched in the optical fabric.  These are longer than the labels
   defined in GSMPv3 as they have physical and structural context.  As

Kullgren, et. al.        GSMP WG - June 2002                        2
                 draft-ietf-gsmp-reqs-02.txt     December 2002

   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 [5]
        - 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. Therefore the
   ability to perform operations on groups of the above labels MUST
   also be supported (e.g., 5 OC-3s, contiguous wavebands)

6.1.2. Label Management Issues

   An updated label range message MUST be provided.  There MUST also be
   support of multiplexing (e.g. no multiplexing, SONET, Gigabit
   Ethernet multiplexing etc).

6.2. Statistics messages

   Optical switches have a number of different statistics which are not
   in common with ATM, or Frame Relay switches.  Consequently, the
   statistics messages SHOULD be updated to report Performance
   Monitoring statistics defined for all new optical transport
   technologies added to GSMP.

6.3. Configuration Issues

6.3.1. Switch Configuration

6.3.1.1. Layer Switching Identification

   Since an Optical Switches may be able to provide connection services
   at multiple transport layers (i.e. STS-3c, STS-1, VT-1.5, DS3, DS1),
   and not all switches are expected to support the same transport
   layers, the switch will need to notify the controller of the
   specific layers it can support.

   Therefore, the Switch Configuration message MUST be extended to
   provide a list of the transport layers for which an optical switch
   can perform switching.

Kullgren, et. al.        GSMP WG - June 2002                        3
                 draft-ietf-gsmp-reqs-02.txt     December 2002

6.3.2. Port Configuration

   The port configuration message supplies the controller with the
   configuration information related to a single port. Consequently,
   extensive additions will need to be made to this command.

6.3.2.1. Port Type extensions

   Port types MUST be added to support the mix of optical signals that
   can operate over a single fiber.

   The port information that MAY need to be conveyed includes[6]:

        - wavelengths available per interface
        - bit rate per wavelength
        - type of fiber

6.3.2.2. Supported Signal Type extensions

   Since a port on an optical switch may support signals at multiple
   transport layers, it is necessary to understand the signals
   supported, as well as the possible ways that one signal can be
   transported within another.

   For OTN, SONET/SDH and PDH optical switches, the Port configuration
   message MUST be extended to detail the different transport layer
   signals that are supported by a port.  Furthermore, this extension
   MUST detail which signals may be transported by another signal.

   This mechanism MUST also provide information about optional
   capabilities (such as virtual concatenation and arbitrary
   concatenation for SONET/SDH) available on a port.

6.3.2.3. Trace Mechanism support Identification

   A number of transport layer signals include overhead channels that
   can be used to identify the source of a signal.  Since they are
   embedded in the signal, only the network element has access to the
   signals.  However, not all network elements have the capability to
   set or read the messages in these channels on every port.
   Consequently, this port attribute needs to be reported to the
   controller.

   The Port Configuration message MUST be extended to report which
   trace mechanisms are supported by a port.

6.3.2.4. Port Location Identification

   Since contemporary Optical switches have the ability to support tens
   of thousands of ports in hundreds of shelves located in as
   potentially as many bays, the current "Slot/Port" location
   identifier is inadequate.

Kullgren, et. al.        GSMP WG - June 2002                        4
                 draft-ietf-gsmp-reqs-02.txt     December 2002

   The Slot/Port Location Identifier MUST be extended to encode
   Bay/Shelf/Slot/Port.

6.3.2.5. Port-related Partitioning Extensions

   Partitioning can be done for any resource that exists in the network
   element.  The GSMP partitioning draft currently defines ports and
   switching resources as partitionable resources.  Since optical
   switches may support multiple transport network layers, an
   additional resource type is introduced: the transport layer signal.

   The point where a transport layer signal is inserted into a lower
   layer signal (called an "access point" by the ITU[7]), 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.

6.3.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.

6.4. 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[4].  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.

6.4.1 Transparent Optical

   Capability to control re-timing and re-shaping on a per port level
   MUST be added.

6.4.2 SONET/SDH and OTN

   The capability to control the adaptation parameters used when a
   transport signal is inserted into another transport signal MUST be
   added.  These parameters SHOULD be modifiable at times other than
   adding a branch so that functions such as Tandem Connection
   Monitoring can be configured.Currently, the default set of service
   models in GSMP are all based on the services models defined
   elsewhere, e.g. the Intserv model[8][9],  the Diffserv[10] model,
   ATM QoS models and the Frame relay forum QoS models. A determination
   needs to be made of the applicable service models for optical

Kullgren, et. al.        GSMP WG - June 2002                        5
                 draft-ietf-gsmp-reqs-02.txt     December 2002

   channel trails. These models MUST then be mapped to the GSMP
   capability set mechanism.

6.5. 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).

   A new encapsulation SHOULD be defined allowing the use of a non-IP
   raw wavelength control connection.

   Likewise, a new encapsulation SHOULD be defined allowing GSMP to be
   used in legacy DCN environments that use OSI CLNP.

6.6. MIB Issues

   If a new encapsulation is defined, then the encapsulation group
   SHOULD be updated.  No other changes should be required.

6.7. OXC Transaction Model

6.7.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 behavior.

6.7.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.

Kullgren, et. al.        GSMP WG - June 2002                        6
                 draft-ietf-gsmp-reqs-02.txt     December 2002

6.8. 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 behavior 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.  Consequently, the GSMP port configuration command MUST
   be extended to allow autonomous protection behaviors to be
   provisioned into the Network Element.

   Furthermore, the controller MUST be able to provide the parameters
   for when reversion from a backup link to the original link is
   allowed.  This may take form of hold-off timers, BER parameters, or
   the requirement for controller directed reversion.

6.8.1. Non-Reserved Protection Links

   An example of protection OXC behavior 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., 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.

6.8.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

Kullgren, et. al.        GSMP WG - June 2002                        7
                 draft-ietf-gsmp-reqs-02.txt     December 2002

   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.

   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., 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.

   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.

6.8.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.

Kullgren, et. al.        GSMP WG - June 2002                        8
                 draft-ietf-gsmp-reqs-02.txt     December 2002

6.8.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, signaling clients could define a path protection scheme
   over multiple GSMP enabled OXCs.  This is for further study.

6.9. Controller directed restoration

   Bi-directional Connection Replacement

   Connections in the transport network are inherently point-to-point
   bi-directional.  Unfortunately, GSMPv3 currently does not allow for
   the B and R flags to be set on a add branch message.  This means
   that it is not possible to do an atomic replacement of a bi-
   directional connection -- an action that is desirable for controller
   directed restoration.  Consequently, the protocol MUST be changed to
   allow these flags to be used at the same time.

6.10 GSMP support for optical cross-connect system

   The cross-connect system such as photonic cross-connect, transparent
   optical cross-connect, opaque cross-connect and traditional TDM
   switch can be consist of not only cross-connect (/switch) function,
   but also multiplexing function (including transmission function),
   path termination function (including client signal termination
   function). In the optical cross-connect (OXC) system, the
   multiplexing function corresponds to the wavelength division
   multiplexing (WDM). The optical regenerator and wavelength converter
   may be necessary in order to realize long-haul transmission and to
   use effectively the wavelength resource respectively. Figure 1 shows
   the generalized OXC functional block. The OXC system shown in Fig.1
   should be controlled / managed by GSMP. The advantage of this
   concept is that the GSMP can control the OXC system, without other
   control protocols. This will reduce the cost and time of OXC control
   application development. To control the OXC system, the control
   concept of both connection termination and trail termination for
   each optical label switched path or WDM sections (defined in G.872;
   OMS and OTS) should be introduced in the GSMP. The GSMP for optical
   switch can be located as subset of that for optical cross-connect.

Kullgren, et. al.        GSMP WG - June 2002                        9
                 draft-ietf-gsmp-reqs-02.txt     December 2002

           +-------------+-------------------+-----------+
        -->|             |                   |           |
     WDM   | Wavelength  | Opt. regenerator/ | Opt.      |
   signals | demultiplex/| Wavelength        | switch    |
           | multiplex   | converter         |           |
        <--|             |                   |           |
           +-------------+-------------------+-----------+
                                                ||    ||
                              Client         +-----------+
                            signals (In)  -->| Path      |
                              Client         | terminator|
                            signals(Out)  <--|           |
                                             +-----------+

               Figure 1 General OXC functional block

7. Requirements from Implementors

7.1. GSMP Packet Format

   The Basic GSMP Message Format in chapter 3.1.1 in [5] describes the
   common fields present in all GSMP messages except for the Adjacency
   protocol.

7.1.1. Message segmentation

   If a message exceeds the MTU of the link layer it has to be
   segmented. This was originally done with the "More" value in the
   Result field. The addition of the I flag and the SubMessage Number
   to the header has made the "More" value in the Result field
   obsolete. A clarification of the I flag and SubMessage Number is
   also needed.

7.1.1.1. "More" Result Value

   The "More" value should not be used in GSMP. A request message with
   the Result field set to "More" SHOULD be answered with a failure
   response with a Code field indicating the type of failure.

7.1.1.2. SubMessage Number

   The definition of the SubMessage field should indicate if the
   submessages are numbered starting with 0 or 1.

7.1.1.3. I flag

   The value of the I flag for messages which are not segmented is
   unspecified.

Kullgren, et. al.        GSMP WG - June 2002                       10
                 draft-ietf-gsmp-reqs-02.txt     December 2002

7.1.1.4. Updated Messages

   The "Report Connection State Reply Message" and "All Ports
   Configuration Message" should be rewritten to use the I flag instead
   of the More flag.

7.1.1.5. Message Segmentation example

   A description of how to segment a message should be provided. The
   definition of the Length field should state if each segment should
   contain the total GSMP message length or the length of the segment.

7.1.2. Transaction Identifier

   The Transaction Identifier in [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 send 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.

7.2. Window Size

   The Switch Configuration Message defined in chapter 8.1 in [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.

7.2.2. Retransmission

   A retransmission policy should be used if no reply is received for a
   message with "AckAll" set.

Kullgren, et. al.        GSMP WG - June 2002                       11
                 draft-ietf-gsmp-reqs-02.txt     December 2002

7.3. Delete Branches Message

   The "Delete Branch Element" has a 4 bit Error field that should be
   redefined to match the size of the "Failure Response Codes".

7.4. Adjacency

   The chapter about how to handle a new adjacency and re-established
   adjacencies should be clarified.

7.4.1. Loss of Synchronization

   If a controller looses synchronization, the draft requires the
   switch to reset the connection state. This should be redefined since
   more than one controller may be synchronized to a switch partition.

   This change will affect the definition of the PFlag.

7.5. ReturnReceipt Result value in Events

   When the GSMP V3 initially was defined the events was supposed to be
   generated in a similar fashion as SNMP Traps. When an event was sent
   it was a uni-direction message and there was no requirement of the
   switch to verify that a controller received the message. Since event
   messages never expected a reply of a sent message there where no
   need of a Transaction Identifier. In the case of Event Messages the
   Transaction Identifier was decided it SHOULD be set to zero.

   Later on, a new Result Value of ReturnReceipt was introduced.
   ReturnReceipt is a results field used in Events to indicate that a
   switch requires an acknowledgment for the message.

   Introduced at the same time was the allowance of Multiple
   Controllers jointly controlling the same partition.

   Since all Transaction Identifiers is set to zero in the case of
   Event Messages the following problem can occur.

   1. A switch has multiple controllers jointly controlling a
      partition.
   2. The switch is configured to require acknowledgment of sent
      events.
   3. For some reason one or more controller can not send the
      acknowledgment.
   4. The switch has no ability to find out which controller that did
      not respond.

Kullgren, et. al.        GSMP WG - June 2002                       12
                 draft-ietf-gsmp-reqs-02.txt     December 2002

8. Security Considerations

   The security of GSMP's TCP/IP control channel has been addressed in
   [11]. Any potential remaining security considerations are not
   addressed in the current revision of this draft.

9. Acknowledgements

   The list of authors provided with this document is a reduction of
   the original list. Currently listed authors wish to acknowledge that
   a substantial amount was also contributed to this work by: Avri
   Doria and Kenneth Sundell

   The authors would like to acknowledge the careful review and
   comments of Dimitri Papadimitriou and Torbjorn Hedqvist.

10. References

   1  Ashwood-Smith, D., et. al., "Generalized MPLS - Signaling
      Functional Description," Internet Draft draft-ietf-mpls-
      generalized-signaling-08.txt (work in progress), April 2002.

   2  Mannie, E., et. al., "Generalized Multi-Protocol Label Switching
      (GMPLS) Architecture," draft-ietf-ccamp-gmpls-architecture-02.txt
      (work in progress), March 2002.

   3  International Telecommunications Union, "Architecture for the
      Automatic Switched Optical Network," G.8080, October 2001.

   4  Doria, A, Sundell, K, Hellstrand, F, Worster, T, "General
      Switch Management Protocol V3," RFC 3292, June 2002.

   5  Sadler, J., Mack-Crane, B., "TDM Labels for GSMP," draft-sadler-
      gsmp-tdm-labels-00.txt (work in progress), February 2001.

   6  Rajagopalan, B., et. al., _IP over Optical Networks: A Framework,
      draft-ietf-ipo-framework-02.txt (work in progress), June 2002.

   7  International Telecommunications Union, "Generic functional
      architecture of transport networks", G.805, March 2000.

   8  Braden, R., "Integrated Services in the Internet Architecture: An
      Overview," RFC1633, June 1994.

   9 J. Wroclawski, "Specification of the Controlled-Load Network
      Element Service," RFC2211, Sep 1997.

   10 Blake, S., et. al., _"An Architecture for Differentiated
      Services," RFC2475, December 1998.

Kullgren, et. al.        GSMP WG - June 2002                       13
                 draft-ietf-gsmp-reqs-02.txt     December 2002

   11 Worster, T, et. al., "GSMP Packet Encapsulations for ATM,
      Ethernet and TCP," RFC 3293, June 2002.

11. Author's Addresses

   Hormuzd Khosravi
   Intel
   2111 NE 25th Avenue
   Hillsboro, OR 97124 USA
   Phone: +1 503 264 0334
   Email: [email-masked]

   Georg Kullgren
   Nortel Networks AB
   S:t Eriksgatan 115 A
   P.O. Box 6701
   SE-113 85 Stockholm Sweden
   Email: [email-masked]

   Jonathan Sadler
   Tellabs Operations, Inc.
   1415 West Diehl Road
   Naperville, IL 60563
   Phone: +1 630-798-6182
   Email: [email-masked]

   Stephen Shew
   Nortel Networks
   PO Box 3511 Station C
   Ottawa, ON
   K1Y 4H7
   Email: [email-masked]

   Kohei Shiomoto
   Email: [email-masked]

   Atsushi Watanabe
   Nippon Telegraph and Telephone Corporation
   807A 1-1 Hikari-no-oka, Yokosuka-shi
   Kanagawa 239-0847, Japan
   Email: [email-masked]

   Satoru Okamoto
   Nippon Telegraph and Telephone Corporation
   9-11 Midori-cho 3-chome, Musashino-shi
   Tokyo 180-8585, Japan
   Email: [email-masked]

Kullgren, et. al.        GSMP WG - June 2002                       14
                 draft-ietf-gsmp-reqs-02.txt     December 2002

Full Copyright Statement

   "Copyright (C) The Internet Society (date). 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

Kullgren, et. al.        GSMP WG - June 2002                       15
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================