Internet Draft


MPLS Working Group                                       Ben Mack-Crane
Internet Draft                                            Vishal Sharma
Document: 
Category:
Expires: May 2001                                        Greg Bernstein
                                                                  Ciena

                                                            Eric Mannie
                                                                    GTS

                                                       Bala Rajagopalan
                                                          Debanjan Saha
                                                                Tellium

                                                           Jeff Connell
                                                       Shash Chatterjee
                                                          Mike Raftelis
                                                    White Rock Networks

                                                          November 2000



        Enhancements to GMPLS Signaling for Optical Technologies
          

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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.

1. Abstract

   GMPLS [2] has now been proposed as an extension to the MPLS
   framework to include non packet-switched optical technologies, such
   as time-division multiplexing (PDH/SDH/SONET) and wavelength
   division multiplexing (lambdas/fibers). This draft proposes an
   enhanced label request format for such optical technologies, which
   accounts for some special characteristics of these technologies
   (see, for instance, [3], [4], [5])that differentiate them from

Mack-Crane et al           Expires May 2001                          1

draft-mack-crane-gmpls-signaling-enhancements-00.txt      November 2000


   packet-switched technologies. When enumerating our encoding, we
   focus, for clarity, on optical TDM technologies, since the standards
   for these are well-defined, but it will be seen that the proposal
   has very general applicability.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [6].


3. Why is this Refinement Needed?

   The signaling refinements proposed in this draft come from the
   recognition of a fundamental distinction between non packet-switched
   and packet-switched technologies. Namely, that in the non-packet
   switched case, a link is capable of switching a small (fixed) number
   of discrete signals, which we call "link connections," and that an
   LSP may be comprised of one of these discrete signals, thus
   requiring a particular link connection capability at a switch.
   Thus, an intermediate switch must know the signal type of an LSP
   that desires to go through it, to determine if it has the correct
   link connection(s) to switch that LSP. In the optical TDM world,
   these link connections take the form of signals in the SDH/SONET
   multiplex [3], [5], which is a systematic arrangement of different
   TDM signals in a multiplexing tree or hierarchy [3], while in the
   optical WDM world they may (among other things) take the form of
   signals transmitted at discrete wavelengths/frequencies, with some
   particular, even spacing between them [5], such as 100 GHz, 50 GHz,
   or 25 GHz. In other words, each non packet-switched link is capable
   of carrying over it a certain number and type(s) of link
   connections, which are switched by the switching element.

   By contrast, in packet- or cell-multiplexed links, the "link
   connections" that are available are flexible, ranging continuously
   from those with a certain minimum bandwidth to those with a certain
   maximum bandwidth. For instance, a POS link can accommodate any
   packet LSP with a bandwidth up to the maximum available bandwidth of
   the link, or any combination of LSPs such that their aggregate
   bandwidth does not exceed what is allowed by connection admision
   control . In this case, one may distinguish between the link
   connections based on their bandwidth, since there is only one type
   of signal (comprised of IP packets) that such a link carries.

   With optical TDM links, however, it is crucial to know the switching
   capability supported by the end of a link, because it determines
   which hierarchy a link supports, and the types of link connections
   within that multiplex hierarchy that the link supports. Since the
   link connections provided by a link are of fixed, discrete types,
   the link connections suitable for carrying an LSP are now limited to
   those that match the nature or type of the LSP (we make this more
   precise in Sections 5 and 6), or to which the LSP can be readily

Mack-Crane, et al.         Expires May 2001                          2

draft-mack-crane-gmpls-signaling-enhancements-00.txt      November 2000


   adapted (by mapping it to a container, for instance). The situation
   is futher complicated by the fact that a given interface may support
   multiple levels (or multiple types of link connections) of a TDM
   hierarchy, or indeed multiple hierarchies [5].

   Thus, it is necessary to indicate the signal type of the LSP so that
   an intermediate node can select those links that support link
   connections suitable for carrying that LSP. (Obviously, this also
   impacts link-state advertisements in IGP routing, but that is
   alluded to elsewhere[5].)


4. What is Required?

   What is required to specify the nature of the desired LSP,
   therefore, is not merely the particular network layer (or
   technology) at which an LSP is established (currently captured in
   the LSP Encoding Type [2] field of the Label Request in the GMPLS
   draft), but also the particular signal type, within the technology
   represented by the LSP Encoding Type.  Thus, for the optical TDM
   case, it is not enough to merely know that the LSP is a SONET LSP,
   it is also imperative to know whether it is signal type STS-1 or
   VT1.5, since an LSP with signal type STS-1 cannot, for instance, be
   routed over a link that only has VT1.5 link connections available,
   even if the unused bandwidth exceeds that needed for an STS-1 signal
   type. Thus, what is required is a Signal Type field in addition to
   the LSP Encoding Type field, so that this new field can be used to
   identify (via appropriate rules), the specific link connections that
   can be used to carry this LSP over a link.

   Another element specifying the nature of the desired LSP is the
   extent, if any, of connection grouping, which is specified by a
   combination of two fields that denote respectively, the type of
   grouping requested by the LSP and the number of components in that
   grouping. For example, in optical TDM networks, a number of non-
   concatenated STS-1s that are routed together as a group (all
   contained within the same SONET line or WDM signal) receive
   essentially the same delay and propagation, so they are specified by
   a requested grouping type (RGT) field in GMPLS. This denotes how
   many connections of a given signal type are requested together, and
   helps to ensure that they meet similar routing constraints. Since
   the specific group routing constraints depend on technology, this
   parameter is interpreted in the context of the LSP Encoding Type
   field.

   Such grouping simplifies connection establishment (especially for
   batches of DS-3s that are being wholesaled) and speeds re-routes.
   The grouping of larger signals, i.e., groups of STS-Mc, lambdas,
   etc., is for further study.

   Finally, there is also a field that indicates the requested number
   of components (RNC), that is, the number of identical signal types


Mack-Crane, et al.         Expires May 2001                          3

draft-mack-crane-gmpls-signaling-enhancements-00.txt      November 2000


   that are requested to be grouped into an LSP, as specified in the
   RGT field.


5. A Discussion of the Refinements

   To summarize, the refinements proposed in this document are:

   i)   The introduction of a new field, that is interpreted in the
        context of the LSP Encoding Type field, and specifies the
        Signal Type of the LSP, allowing for an intermediate switch to
        decide which links are capable of supporting the requested LSP.

   ii)  A modification of the payload identifier field (the GPID), so
        that it is interpreted in the context of the LSP Encoding Type
        field. This tiered structure (as opposed to the flat structure
        in the current GMPLS specification) facilitates understanding
        and extensibility, by allowing for newer payload types for a
        particular technology to be added without conflict
        (coordination or confusion) with other technologies.


   iii) The introduction of an "Extra Traffic" code in the Link
        Protection Type/Flag field, which, in effect, realizes a
        service class that provides a level of reliability even lower
        than that achieved by the use of unprotected links at each hop.
        (Recall, that an LSP routed over "Extra Traffic" links could
        fail even if there is no fault on the links that this LSP is
        using, since an extra traffic link may be pressed into service
        when a corresponding working path has a fault.)

        We emphasize that the Link Protection Flag field is associated
        with  a link between two nodes, and reflects the participation
        of that link in some protection scheme. That is, it reflects
        how the link at a particular hop is protected or used in
        protection by a server layer or path layer protection
        mechanism. We have kept this as a distinct option, without
        mixing it with notions of pre-emption and priority (P&P) for
        the following reasons.

        LPF represents both a property of a link (advertised in
        routing) and a constraint on which links may be used for a
        given path (utilized in signaling).  In both uses, however, the
        LPT value indicates a property of a link that is derived from
        the server layer network providing that link or a path
        protection mechanism at the LSP layer.


6. Proposed Encoding for TDM Optical Technologies: Label Related
Formats

   This section outlines the refined encodings for the various fields
   discussed in detail in the preceding sections (Sections 4 and 5).

Mack-Crane, et al.         Expires May 2001                          4

draft-mack-crane-gmpls-signaling-enhancements-00.txt      November 2000



6.1 Generalized Label Request

   The format of a Generalized Label Request (in RSVP) is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             | Class Num (19)|C_Type (5)[TBA]|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LSP Enc. Type |  Signal Type  |             G-PID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Link Prot Flags|       |  RGT  |              RNC              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format of a Generalized Label Request (in CR-LDP) is:

   0                   1                   2                     3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|          0x0902           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LSP Enc. Type |  Signal Type  |             G-PID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Link Prot Flags|       |  RGT  |              RNC              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   LSP Encoding Type: 8 bits

   Indicates the encoding technology of the LSP being requested.  The
   following shows permitted values and their meaning:

                 Value       Type
                 -----       ----
                   3         ANSI PDH
                   4         ETSI PDH
                   5         SDH
                   6         SONET

   The ANSI PDH and ETSI PDH types designate these respective
   networking technologies.  DS1 and DS3 are examples of ANSI PDH LSPs.
   An E1 LSP would be ETSI PDH.  The SDH and SONET types designate
   synchronous TDM multiplexing technologies.  VT1.5 and STS-1 are
   examples of SONET LSPs.  SDH LSP types include VC-12, VC-4, etc.

   NOTE: The following encodings are an example of how Signal Type, G-
   PID, etc. encoding might be done for PDH, SDH, and SONET.  A
   specific encoding proposal will be provided after these and other
   possible encodings are considered.

   Signal Type: 8 bits




Mack-Crane, et al.         Expires May 2001                          5

draft-mack-crane-gmpls-signaling-enhancements-00.txt      November 2000


   Indicates the specific signal type of the LSP being requested.  This
   field is interpreted according to the technology specified by LSP
   Encoding Type.  The Signal Type provides transit switches with the
   information required to determine which link connections
   (timeslots/labels) can support the LSP.

   Permitted values and their meaning for LSP Encoding Type ANSI-PDH:

                 Value       Type
                 -----       ----
                   1         DS1 SF
                   2         DS1 ESF
                   3         DS2
                   4         DS3 M23
                   5         DS3 C-bit Parity
                   6         DS4

   Permitted values and their meaning for LSP Encoding Type ETSI-PDH:

                 Value       Type
                 -----       ----
                   1         E1
                   2         E2
                   3         E3
                   4         E4

   Permitted values and their meaning for LSP Encoding Type SDH:

                 Value       Type
                 -----       ----
                   1         VC-11
                   2         VC-12
                   3         VC-2
                   4         TUG-2
                   5         VC-3
                   6         TUG-3
                   7         VC-4
                   8         STM-1
                   9         STM-1 MS
                  10         STM-1 RS
                  12         STM-4
                  13         STM-4 MS
                  14         STM-4 RS
                  16         STM-16
                  17         STM-16 MS
                  18         STM-16 RS
                  20         STM-64
                  21         STM-64 MS
                  22         STM-64 RS
                  24         STM-256
                  25         STM-256 MS
                  26         STM-256 RS


Mack-Crane, et al.         Expires May 2001                          6

draft-mack-crane-gmpls-signaling-enhancements-00.txt      November 2000


   The "STM-N MS" and "STM-N RS" Signal types represent transparent STM
   Multiplex Section and Regenerator Section LSPs respectively.  Simply
   "STM-N" signifies path layer transparency, that is, the set of AUs
   contained within the STM-N taken as a group (equivalent to AUG-N).
   These are defined for the standard values of N (1, 4, 16, 64, 256).

   The group Signal Types (TUG-2, TUG-3, STM-N) signify that the entire
   contents of the group are to be connected.  This requires that
   proper pointer processing be done for each constituent of the group,
   according to the contents of the pointers present in the LSP.

   Permitted values and their meaning for LSP Encoding Type SONET:

                 Value       Type
                 -----       ----
                   1         VT1.5
                   2         VT2
                   3         VT3
                   4         VT6
                   5         VTG
                   6         STS-1
                   7         OC-1 Line
                   8         OC-1 Section
                  10         OC-3 Path Group
                  11         OC-3 Line
                  12         OC-3 Section
                  14         OC-12 Path Group
                  15         OC-12 Line
                  16         OC-12 Section
                  18         OC-48 Path Group
                  19         OC-48 Line
                  20         OC-48 Section
                  22         OC-192 Path Group
                  23         OC-192 Line
                  24         OC-192 Section
                  26         OC-768 Path Group
                  27         OC-768 Line
                  28         OC-768 Section

   SONET group (VTG, OC-n Path Group) and OC-N transparent line/section
   Signal Types are defined in the same way as their SDH counterparts
   above.


   Generalized PID (G-PID): 16 bits

   An identifier of the payload carried by an LSP, i.e. an identifier
   of the client layer of that LSP.  This must be interpreted according
   to LSP Encoding Type and is used by the nodes at the endpoints of
   the LSP.  Standard Ethertype values are used for packet and Ethernet
   LSPs; other values are:



Mack-Crane, et al.         Expires May 2001                          7

draft-mack-crane-gmpls-signaling-enhancements-00.txt      November 2000


   When the technology encoding type is ANSI-PDH, GPID can take the
   following values:

                 Value       Client Type
                 -----       -----------
                   0         Unknown

   When the technology encoding type is ETSI-PDH, GPID can take the
   following values:

                 Value       Client Type
                 -----       -----------
                   0         Unknown

   When the technology encoding type is SDH, GPID can take the
   following values:

                 Value       Client Type
                 -----       -----------
                   0         Unknown
                   1         Asynchronous mapping of E4
                   2         Asynchronous mapping of DS3
                   3         Asynchronous mapping of E3
                   4         Bit synchronous mapping of E3
                   5         Byte synchronous mapping of E3
                   6         Asynchronous mapping of DS2
                   7         Bit synchronous mapping of DS2
                   8         Byte synchronous mapping of DS2
                   9         Asynchronous mapping of E1
                  10         Byte synchronous mapping of E1
                  11         Byte synchronous mapping of 31 * DS0
                  12         Asynchronous mapping of DS1
                  13         Bit synchronous mapping of DS1
                  14         Byte synchronous mapping of DS1
                  15         ATM mapping

   When the technology encoding type is SONET, GPID can take the
   following values:

                 Value       Client Type
                 -----       -----------
                   0         Unknown
                   1         DS1 SF Asynchronous
                   2         DS1 ESF Asynchronous
                   3         DS3 M23 Asynchronous
                   4         DS3 C-Bit Parity Asynchronous
                   5         VT
                   6         STS
                   7         ATM
                   8         POS

   Link Protection Flags: 8 bits



Mack-Crane, et al.         Expires May 2001                          8

draft-mack-crane-gmpls-signaling-enhancements-00.txt      November 2000


   The Link Protection Flag field,  carried in the label request
   message,  is a vector of flags indicating the protection level(s)
   that the LSP desires for the links at each hop along its path. It
   is, therefore, distinct from MPLS-level protection (see 7), which
   involves protection of the actual LSP (which may be done either end-
   to-end, via path-based protection, or locally. A value of 0 implies
   that this connection does not care about which, if any, link
   protection is used.  More than one bit may be set to indicate when
   multiple protection types are acceptable.  When multiple bits are
   set and multiple protection types are available, the choice of
   protection type is a local (policy)decision.

   The following flags are defined:

   0x01  Extra Traffic

   Indicates that links that are reserved for automatic recovery in
   case of a fault elsewhere in the network may be used for this LSP.
   Observe that this means that the LSP can be disrupted whenever such
   a link is needed for its assigned recovery purpose. In other words,
   the LSP can be dropped even if there is no fault on the links along
   which this LSP is routed.

   0x02  Unprotected

   "Unprotected" indicates that unprotected links may be used by this
   LSP. This means that the LSP will only lose service on this hop, if
   there is a fault along this particular link (a fault elsewhere will
   not affect this link, and therefore will not affect this LSP). In
   other words, "unprotected" can be regarded as a "neutral" form of
   protection. The LSP does not lose service as long as the link is up,
   but loses service once this link goes down, since the link itself is
   not protected by a backup link.

   0x04  Shared

   Indicates that protected working links, whose protection resources
   are shared among some number, say N,  of working links may be used
   by this LSP.

   This means that if there is a fault along this particular link, the
   LSP will lose service on this hop, only if the backup link is
   already in use by traffic from one of the remaining N-1 working
   links (due to an earlier fault on one of those links). Thus, the
   "shared" option can be regarded as a better form of protection,
   since the LSP is protected as long as there is no fault on any of
   the remaining N-1 working links that share the same backup link.


   0x08  Dedicated

   Indicates that links with dedicated protection, e.g., 1:1 or 1+1
   protection, may be used by this LSP.


Mack-Crane, et al.         Expires May 2001                          9

draft-mack-crane-gmpls-signaling-enhancements-00.txt      November 2000



   This means that a protection link is reserved for the working link
   over which this LSP is routed, so that this LSP is always protected
   against any fault on its working link. Thus, the "dedicated" option
   offers a higher form of link-level protection.


   0x10  Enhanced

   Indicates that links that are multiply protected, such as via a ring
   switch and a span switch in a 4-fiber BLSR/MS-SPRING, may be used by
   this LSP.

   Thus, the LPFs represent a constraint on which links may be used for
   a given path (which is signaled during connection setup as specified
   above).


   Requested Grouping Type (RGT): 4 bits

   This field indicates the type of grouping requested for the LSP.
   A number of Signal Type connections may be requested with certain
   routing constraints.  The specific group routing constraints may
   depend on the technology, so this field is interpreted in the
   context of LSP Encoding Type.

    The values for SONET and SDH are defined in the following table:

                 Value       Grouping Type
                 -----       ----------------------------------
                   0         No Grouping
                   1         Co-routed group
                   2         Virtual concatenation
                   3         Contiguous standard concatenation
                   4         Contiguous arbitrary concatenation

   For a co-routed group, all components in the group must be routed
   via the same higher order container.  Virtual concatenation requires
   co-routing and implies a bonding function at the endpoints of the
   group.  For contiguous standard concatenation, there must be a
   standard number of components (4, 16, 64, etc. for SDH; 3, 12, 48,
   etc. for SONET), and they must be in one higher order container.
   For contiguous arbitrary concatenation, the number of components is
   arbitrary (2, 3, 4, ą) and they still must be routed in one higher
   order container.

   Requested Number of Components (RNC): 16 bits

   This field indicates the number of identical signal types that are
   requested to be grouped in that LSP, as specified in the previous
   field.  It is assumed that all these components have identical
   characteristics. This field is set to zero if no grouping is
   requested.

Mack-Crane, et al.         Expires May 2001                         10

draft-mack-crane-gmpls-signaling-enhancements-00.txt      November 2000




7. Rationale for the General Applicability of these Refinements

   As seen from the explanations in the preceding sections, the
   refinements introduced in this draft are not specific to the optical
   TDM layer alone. The notion of a Signal Type is general, and will be
   needed in optical WDM networks, at least to distinguish between
   different wavelength spacings, by charaterizing a signal by its
   center frequency (see [5], for example). Of course, the optical WDM
   technolgoies, being new, do not yet have all the requisite standards
   in place, which makes it even more imperative that the encodings
   defined in the GMPLS work be flexible, extensible, and applicable to
   various technologies.

   Likewise, the notion of "Extra Traffic," which is a common one in
   optical TDM networks, we believe has more general applicability.
   Since LPF represents a property of a link, it can, be used in a
   recursive way in multi-layer networks.

   The RGT and RNC are similarly general concepts, since the notion of
   co-routed groups can easily apply to other layers, such as the
   optical WDM layer. Also, this method of establishing co-routed
   groups has some advantages over doing LSP setup repeatedly for all
   the components in a co-routed group (and giving them the same ERO),
   because it eliminates the scenario where some components get blocked
   due to resource contention from other requests that arrive at the
   intermediate nodes while the various components of the co-routed
   group are still be set up. Furthermore, it allows for a switch to
   locally route the groups in an identical way (via the same
   interfaces, ports, etc.), which has benefits for protection and
   recovery.

   As such, the refinements proposed in this document, while
   illustrated in the context of optical TDM networks, are general
   enough for adoption in the label request of the GMPLS specification.
   Below we give two suggestions for how these might be incorporated in
   GMPLS.

8. Proposed Options for the Adoption of the Refinements

   There are two options for the adoption of these refinements. The
   first option is for the label request in GMPLS to be enhanced to the
   format specified in this document. Operators or users that do not
   require certain fields can simply set the associated bits to a
   "donĘt care" value. This requires no other changes to the GMPLS
   signaling specification, and is in conformance with the
   specification of the bandwidth value for an LSP in the T-Spec object
   in RSVP and in an appropriate bandwidth TLV in CR-LDP.  It also has
   the advantages of not requiring further C-types (per technology) for
   the Label Request object, and allow for a general label request
   object, while still allowing the flexibility for technology-specific
   variations, where needed.

Mack-Crane, et al.         Expires May 2001                         11

draft-mack-crane-gmpls-signaling-enhancements-00.txt      November 2000



   The second option is to simply adopt the refined label request
   encoding for the SONET/SDH/PDH GMPLS label request (with C-type 5).
   As shown in this document, in that case values that are not relavant
   for the optical TDM layer (for example, digital wrapper, lambda, or
   fiber) should be eliminated from the LSP Encoding Type, Signal Type
   and GPID. Likewise, values corresponding to the optical TDM layer
   would have to be removed from the label request object, C-type 4,
   currently defined in the GMPLS draft, so that there is always only
   one way to encode the label request for a given network layer or
   given LSP Encoding Type.


9. Security Considerations

   This draft raises no new security issues in the GMPLS
   specifications.


10. References


   [1]  Bradner, S., "The Internet Standards Process -- Revision 3",
      BCP 9, RFC 2026, October 1996.

   [2]  Ashwood-Smith, P., and Berger, L., Editors, "Generalized MPLS:
      Signaling Functional Description," Internet Draft, Work in
      Progress, draft-ieft-mpls-generalized-signaling-01.txt, November
      2000.

   [3]  Bernstein, G, Mannie, E., Sharma, V. et al, "MPLS-based Control
      of SDH/SONET Optical Networks," Internet Draft, Work in Progress,
      draft-bernstein-mpls-sdh-sonet-control-00.txt, November 2000.

   [4] Chiu, A., and Strand, J., Unique Features and Requirements for
      the Optical Layer Control Plane, Internet Draft, Work in
      Progress, draft-chiu-strand-unique-oclp-00.txt,  July 2000.

   [5] Bernstein, G., and Sharma, V., "Some Comments on GMPLS and
      Optical Technologies," Internet Draft, Work in Progress, draft-
      bernstein-mpls-optical-00.txt, November 2000.

   [6]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997

   [7]  Makam, V., et al "A Framework for MPLS-based Recovery,"
      Internet Draft, Work in Progress, draft-ieft-mpls-recovery-
      frmwrk-00.txt, September 2000.

11. Acknowledgements

   We would like to acknowledge all of our colleagues and co-authors on
   the GMPLS signaling specifications [2], who on several occasions

Mack-Crane, et al.         Expires May 2001                         12

draft-mack-crane-gmpls-signaling-enhancements-00.txt      November 2000


   conferenced with us, helped us to distill these ideas, and
   encouraged those of us more closely familiar with optical TDM
   technologies to clearly articulate the ideas presented here.


12. Author's Addresses

   Ben Mack-Crane                 Vishal Sharma
   Tellabs  Operations, Inc.      Tellabs Research Center
   4951 Indiana Avenue            One Kendall Sq., Bldg. 100 Ste. 121
   Lisle, IL 60532                Cambridge, MA 02139
   Ph: (630) 512-7255             Ph: (617)577-8760
   Ben.Mack-Crane@tellabs.com     Vishal.Sharma@tellabs.com

   Greg Bernstein                 Eric Mannie
   Ciena Corporation              GTS Operations
   10480 Ridgeview Court          Terhulpsesteenweg 6A
   Cupertino, CA 94014            1560 Hoeilaart, Belgium
   Ph: (408) 366-4713             Ph:  +32 2 658 56 52
   greg@ciena.com                 Eric.Mannie@gts.com

   Bala Rajagopalan               Debanjan Saha
   Tellium, Inc.                  Tellium, Inc.
   2 Crescent Place               2 Crescent Place
   Ocean Port, NJ 07757           Ocean Port, NJ 07757
   Ph: (732) 923-4237             Ph: (732) 923-4264
   braja@tellium.com              dsaha@tellium.com

   Jeff Connell                   Shash Chatterjee
   White Rock Networks, Inc.      White Rock Networks, Inc.
   18111 Preston Road, Suite 900  18111 Preston Road, Suite 900
   Dallas, TX 75252               Dallas, TX 75252
   Ph: (972)588-3762              Ph: (972)588-3700
   JConnell@WhiteRockNetworks.com Schatterjee@WhiteRockNetworks.com

   Mike Raftelis
   White Rock Networks, Inc.
   18111 Preston Road, Suite 900
   Dallas, TX 75252
   Ph: (972)588-3728
   MRaftelis@WhiteRockNetworks.co
   m


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


Mack-Crane, et al.         Expires May 2001                         13

draft-mack-crane-gmpls-signaling-enhancements-00.txt      November 2000


   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
















































Mack-Crane, et al.         Expires May 2001                         14