Subject: [GSMP] draft-ietf-gsmp-reqs-01.txt

From: Georg Kullgren <[email-masked]>
Date: Mon, 4 Mar 2002 09:30:37 +0100

Requirements for adding optical support to GSMPv3
-------------------------------------------------

Here's the new draft-ietf-gsmp-reqs-01.txt from the design team. 

Unfortunately it wasn't submitted in time since I obviously
don't know how to count time-zones.

Regards
/Georg
-- 
------------------------------------------------------------------------
Georg Kullgren            Nortel Networks AB    [email-masked]
System Architect          S:t Eriksgatan 115 A  Tel:   +46-8-50 88 36 18
Routing Architecture Lab  SE-113 85 Stockholm   Mobile: +46-703-14 36 18
                          Sweden                Fax:   +46-8-50 88 35 01

_______________________________________________
GSMP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gsmp

---

From: Georg Kullgren <[email-masked]>
Date: Mon, 4 Mar 2002 09:47:28 +0100

---

From: Georg Kullgren <[email-masked]>
Date: Mon, 4 Mar 2002 10:33:16 +0100

INTERNET DRAFT                                            Georg Kullgren
GSMP Working Group                                          Stephen Shew
                                                         Nortel Networks

                                                        Hormuzd Khosravi
                                                                   Intel

                                                         Jonathan Sadler
                                                                 Tellabs

                                                          Satoru Okamoto
                                                          Kohei Shiomoto
                                                        Atsushi Watanabe
                                                                     NTT

                                                     Expires August 2002

                     <draft-ietf-gsmp-reqs-01.txt>

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

Abstract

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

Kullgren, et. al.          Expires August 2002                  [Page 1]

Internet Draft                GSMP updates                 February 2002

Table of Contents
1. Overview .......................................................... 3
2. Requirements for Optical Support .................................. 3
 2.1. Label Types .................................................... 3
 2.2. Port and Label Management Issues ............................... 4
 2.3. Statistics messages ............................................ 4
 2.4. Configuration Issues ........................................... 4
  2.4.1. Switch Configuration ........................................ 4
  2.4.2. Port Configuration .......................................... 4
  2.4.3. Service Configuration ....................................... 5
 2.5. Service Model Issues ........................................... 5
 2.6. Encapsulation issues ........................................... 5
 2.7. MIB Issues ..................................................... 6
 2.8. OXC Transaction Model .......................................... 6
  2.8.1 Serial Transactions .......................................... 6
  2.8.2. Bulk Transactions ........................................... 6
 2.9. OXC Restoration Capabilities ................................... 6
  2.9.1. Non-Reserved Protection Links ............................... 7
  2.9.2. Dedicated Protection Links .................................. 7
  2.9.3. Protection Triggers ......................................... 8
  2.9.4. Protection Link Capabilities ................................ 8
 2.10 GSMP support to optical cross-connect system ................... 9
3. Requirements from Implementors ................................... 10
 3.1. GSMP Packet Format ............................................ 10
  3.1.1. Message segmentation ....................................... 10
   3.1.1.1. "More" Result Flag ...................................... 10
   3.1.1.2. SubMessage Number ....................................... 10
   3.1.1.3. I flag .................................................. 10
   3.1.1.4. Updated Messages ........................................ 10
   3.1.1.5. Message Segmentation example ............................ 11
  3.1.2. Transaction Identifier ..................................... 11
 3.2. Window Size ................................................... 11
 3.3. Retransmission ................................................ 11
 3.4. Delete Branches Message ....................................... 12
 3.5. Adjacency ..................................................... 12
  3.5.1. Loss of Synchronisation .................................... 12
 3.6. ReturnReceipt Result value in Events .......................... 12
4. Additional Requirements .......................................... 13
5. Security Considerations .......................................... 14
6. Acknowledgements ................................................. 14
7. References ....................................................... 15
8. Author's Addresses ............................................... 17
9. Full Copyright Statement ......................................... 18

Kullgren, et. al.          Expires August 2002                  [Page 2]

Internet Draft                GSMP updates                 February 2002

1. Overview

   This draft is intended to describe the required updates to GSMP
   requested by implementors and the required changes 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
   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. Requirements for Optical Support

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

Kullgren, et. al.          Expires August 2002                  [Page 3]

Internet Draft                GSMP updates                 February 2002

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

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

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

2.3. Statistics messages

   No changes are currently proposed for the statistics messages to
   support optical switching.

2.4. Configuration Issues

2.4.1. Switch Configuration

   No changes are currently proposed for the switch configuration
   messages to support optical switching.

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

Kullgren, et. al.          Expires August 2002                  [Page 4]

Internet Draft                GSMP updates                 February 2002

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

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

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

   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.

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

Kullgren, et. al.          Expires August 2002                  [Page 5]

Internet Draft                GSMP updates                 February 2002

2.7. MIB Issues

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

2.8. OXC Transaction Model

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

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

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

Kullgren, et. al.          Expires August 2002                  [Page 6]

Internet Draft                GSMP updates                 February 2002

   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.

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

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

   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.

Kullgren, et. al.          Expires August 2002                  [Page 7]

Internet Draft                GSMP updates                 February 2002

   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.

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

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

Kullgren, et. al.          Expires August 2002                  [Page 8]

Internet Draft                GSMP updates                 February 2002

2.10 GSMP support to 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.

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

                        Figure 1 General OXC functional block

Kullgren, et. al.          Expires August 2002                  [Page 9]

Internet Draft                GSMP updates                 February 2002

3. Requirements from Implementors

3.1. GSMP Packet Format

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

3.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" flag in the
   Result field.  The addition of the I flag and the SubMessage Number
   to the header has made the "More" flag in the Result field obsolete.
   A clarification of the I flag and SubMessage Number is also needed.

3.1.1.1. "More" Result Flag

   The "More" flag 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.

3.1.1.2. SubMessage Number

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

3.1.1.3. I flag

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

3.1.1.4. Updated Messages

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

Kullgren, et. al.          Expires August 2002                 [Page 10]

Internet Draft                GSMP updates                 February 2002

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

3.1.2. Transaction Identifier

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

3.2. Window Size

   The Switch Configuration Message defined in chapter 8.1 in [6]
   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 the window should be cleared when the
   adjacency is lost and later recovered.

3.2.2. Retransmission

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

Kullgren, et. al.          Expires August 2002                 [Page 11]

Internet Draft                GSMP updates                 February 2002

3.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".

3.4. Adjacency

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

3.4.1. Loss of Synchronisation

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

   This change will affect the definition of the PFlag.

3.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.          Expires August 2002                 [Page 12]

Internet Draft                GSMP updates                 February 2002

4. Additional Requirements

   1. Better Slot/Port definition (Bay/Shelf also needed)
   2. Better Bidirectional support
      Use in Move branch, Delete branch -- need atomic behavior
   3. Better Port Capability identification (needed to find stack of
      supported TTP/CTPs)
      Should be consistent with Neighbor Capability Exchange approaches
      (i.e. LMP)
      Should be consistent with Link attributes used in Routing
   4. Need to identify how to number points in the potential
      sub-multiplex tree
      Use convention in iftable?
      Or should points be refered to via root-ifindex:label,
      and partitioning instantiates new root-ifindexes?
   5. Better Node Capability identification
      Support for LCAS?
   6. Need to allow minimal Port configuration in addition to Matrix
      Connection configuration
   7. How should blocking switch fabrics be handled?
   8. Better Path Switching support
      Need to allow preconfiguration of selector allowing actions
      independant of controller
   9. Rectify how B and R flags interact, since Bidirectional links are a
      fundamental unit in TDM nets
   10.Remove "Layer specific" messages, i.e. ATM VPC Add/Move*/Delete Branch
   11.Partitioning at "any layer" (not just port specific partitioning)
   12.Generalize Statistics Messages (ie ATM vs Frame)
   13.Clarify use of Port/Line Status so it corresponds w/ TDM
      Administrative/Operational state
      Clarify interaction with Port Up/Down Events
   14.Support for transport over OSI TP1 or TP3, and SCTP
   15.Need to correlate Events and only send root cause Event messages

Kullgren, et. al.          Expires August 2002                 [Page 13]

Internet Draft                GSMP updates                 February 2002

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

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

Kullgren, et. al.          Expires August 2002                 [Page 14]

Internet Draft                GSMP updates                 February 2002

7. References

       [1]  Ashwood-Smith, D., et. al.,
            "Generalized MPLS - Signaling Functional Description",
            Internet Draft draft-ietf-mpls-generalized-signaling-07.txt,
            November 2001. Work in Progress.

       [2]  Mannie, E., et. al.,
            "Generalized Multi-Protocol Label Switching (GMPLS)
       Architecture",
            draft-ietf-ccamp-gmpls-architecture-01.txt (work in
            progress), November 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-03.txt (work in
            progress), April, 2001

       [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-11.txt (work in progress),
            December 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-
            03.txt (work in progress), March 2001

       [9]  Sjostrand, H, et al, Definitions of Managed Objects for the
            General Switch Management Protocol (GSMP),"
            Internet-Draft draft-ietf-gsmp-mib-07 (work in
            progress), November 2001.

       [10] Worster, T, et al, "GSMP Packet Encapsulations for ATM,
            Ethernet and TCP," Internet-Draft draft-ietf-
            gsmp-encaps-05 (work in progress), December 2001.

       [11] G.ASON _Architecture for the Automatic Switched Optical

Kullgren, et. al.          Expires August 2002                 [Page 15]

Internet Draft                GSMP updates                 February 2002

            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-ietf-mpls-bundle-01.txt
            (work in progress), November 2001

Kullgren, et. al.          Expires August 2002                 [Page 16]

Internet Draft                GSMP updates                 February 2002

8. Author's Addresses

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

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

       Jonathan Sadler
       Tellabs Operations, Inc.
       1000 Remington Blvd
       Bolingbrook, IL 60440
       Phone: +1 630-848-7741
       Email: [email-masked]

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

       Kohei Shiomoto
       [email-masked]

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

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

Kullgren, et. al.          Expires August 2002                 [Page 17]

Internet Draft                GSMP updates                 February 2002

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

Kullgren, et. al.          Expires August 2002                 [Page 18]

---

From: avri <[email-masked]>
Date: Thu, 07 Mar 2002 00:34:07 +0100

hi,

I am wondering what should the relation of GSMP be to LMP?
And is this something that needs to be covered in the 
requirements?

a.

btw, for anyone who missed Georg's email with the reqs,
since they are not going to make the ID repositroy, i have 
put them in: http://www.cdt.luth.se/babylon/drafts/gsmp/

-- 
Avri Doria

Institute for System Technology   Mobile: +46 73 029 8019 

Lulea University of Technology    Office: +46 920 49 3030 

SE 971-87 Lulea                   [email-masked]
Sweden