MPLS Working Group Ben Mack-Crane Internet Draft Vishal Sharma Document: <draft-mack-crane-gmpls-signaling- Tellabs enhancements-00.txt> 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 <draft-mack-crane-gmpls-signaling-enchancements-00.txt> 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