CCAMP Working Group Eric Mannie (Ebone) Internet Draft Dimitri Papadimitriou (Alcatel) Expiration Date: May 2002 November 2001 GMPLS LSP Bandwidth Modification (LBM) for TDM Networks. draft-mannie-ccamp-gmpls-lbm-tdm-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. 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." To view the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow Directory, see http://www.ietf.org/shadow.html. Abstract This document defines how GMPLS can be used to dynamically modify the bandwidth of a TDM circuit. It focuses first on SONET/SDH and will cover G.709 in a next version. SONET/SDH Bandwidth modification can be indeed achieved in very different ways. It can be done by establishing another circuit between the same source and destination with different characteristics (e.g. signal type) and then by switching the traffic to that new circuit doing a switchover. At the other end of the spectrum, bandwidth modification can be done by dynamically adding or removing SPEs/VCs to a circuit using the concept of virtual or contiguous concatenation. This is ideally achieved in a non-disruptive way and by avoiding double counting (i.e. double reserving) the resources while modifying the bandwidth, by using the concept of make-before-break. This specification focuses on this last case. Bandwidth modification is in practice easier to do when virtual concatenation is used since SPEs/VCs don't need to be contiguous, are transported individually and can even be routed independently. E. Mannie et. al. 1 draft-mannie-ccamp-gmpls-lbm-tdm-00.txt November, 01 This can be achieved as well when contiguous concatenation is used but is in practice less likely to happen since a bandwidth increase requires additional free SPEs/VCs physically contiguous at the end of the circuit. This specification also defines how to use multiple differently routed LSPs to build a single SONET/SDH virtually concatenated circuit. Each LSP can be protected/restored individually. 1. Introduction Extensions to GMPLS are defined to control SONET/SDH networks in [GMPLS-SONET-SDH] and [GMPLS-SONET-SDH-EXT]. These extensions define SONET/SDH traffic parameters used to describe in details the type of SONET/SDH LSP (i.e. circuit) being requested. Such a circuit can be requested unidirectional or bi-directional. In some cases it is useful to dynamically change the bandwidth allocated for a SONET/SDH circuit. For instance, it is very useful when Ethernet traffic is transported over SONET/SDH. According to the demand, the size of a concatenated circuit can be modified dynamically without having to reestablish a new circuit, and potentially to interrupt the service. Bandwidth modification can be indeed achieved in very different ways. It can be done by establishing another circuit between the same source and destination with different characteristics (e.g. signal type) and then by switching the traffic to that new circuit doing a switchover. At the other end of the spectrum, bandwidth modification can be done by dynamically adding or removing SPEs/VCs to a circuit using the concept of virtual or contiguous concatenation. This is ideally achieved in a non-disruptive way and by avoiding double counting (i.e. double reserving) the resources while modifying the bandwidth. This specification focuses on this non-disruptive case. In practice, bandwidth modification is easy to achieve thanks to the concept of virtual concatenation, by adding or removing SPEs/VCs, which can be located anywhere, to a virtually concatenated circuit. This can be performed similarly with contiguous concatenation but in practice this method is less likely to happen, e.g. a bandwidth increase can require additional free SPEs/VCs physically contiguous before or after the circuit. Moreover, as currently defined, GMPLS only allows the SPEs/VCs of a virtually concatenated circuit to be co-routed through the same line/multiplex section. This specification removes this limitation E. Mannie et. al. Internet-Draft May 2001 2 draft-mannie-ccamp-gmpls-lbm-tdm-00.txt November, 01 by allowing the same SONET/SDH circuit to be made of several independent LSPs. In that case, LSPs can be set-up, maintained and deleted independently, while being part of the same SONET/SDH circuit. LSPs can be co-routed through the same component TE link, through different components of the same TE link or even routed completely diversely, as far as T1X1/ITU-T requirements for differential delays are respected (out of the scope of this specification). T1X1 and ITU-T are standardizing a similar concept for SONET/SDH and G.709, independently of any distributed control plane and for virtual concatenation only. They have defined a new signaling protocol transported in-band in the overhead. For SONET/SDH, this protocol is transported in the Path Overhead (POH). This protocol is defined in ITU-T Recommendation G.7042 (ex G.lcas) and is called Link Capacity Adjustment Scheme (LCAS) for virtual concatenated signals. LCAS allows increasing or decreasing the capacity of a virtual container that is transported using Virtual Concatenation. In addition, LCAS will automatically decrease the capacity if a member experiences a failure in the network, and increase the capacity when the network fault is repaired. For SDH, LCAS is defined for all VC types for which virtual concatenation is defined, i.e. VC-4, VC-3, VC-2, VC-12 and VC-11. Using LCAS, a VC can only be added at the end of a concatenated signal, but can be removed from any place. This document defines LSP Bandwidth Modification (LBM) procedures and extensions for GMPLS using either virtual concatenation or contiguous concatenation. It first focuses on SONET/SDH and will later cover G.709 with the same approach in a next version. Similarly to GMPLS, this specification covers unidirectional LSPs and bi-directional symmetric LSPs. Bi-directional asymmetric LSPs are not supported today by GMPLS. It should be noted however that today operators do not use such asymmetric LSPs in practice. This specification allows bandwidth modification being requested only by the initiator (source) of a circuit. A next version could cover destination initiated bandwidth modification. However, we expect to cover most of the operational needs using initiator control. This specification could be extended in the future to cover modification of other circuit attributes than the bandwidth, like link protection/restoration characteristics. It focuses first on the SONET/SDH bandwidth modification initiated by the source since it meets the current operational needs. E. Mannie et. al. Internet-Draft May 2001 3 draft-mannie-ccamp-gmpls-lbm-tdm-00.txt November, 01 2. SONET/SDH Virtual and Contiguous Concatenation This section of the draft introduces SDH virtual and contiguous concatenation, this will be extended with a description of the SONET concatenation in a future version. Section 11 of G.707 (April 2000) recommendation defines VC contiguous and virtual concatenation. Contiguous concatenation maintains the contiguous bandwidth through the whole network, while virtual concatenation breaks the contiguous bandwidth into individuals VCs, transports and routes these VCs individually from the source and then recombines them at the path termination. Virtual concatenation requires concatenation functionality only at the path termination equipment, while contiguous concatenation requires concatenation functionality at each network element. Contiguous concatenation is defined for VC-4s to provide a VC-4-Xc (X=4, 16, 64, 256) and for VC-2s in a higher order VC-3 to provide a VC-2-Xc (X=1...7). Other types of non-standard contiguous concatenation are detailed in [GMPLS-SONET-SDH-EXT]. Virtual concatenation is defined for VC-4s, VC-3s, VC-2s, VC-12s and VC-11s but only for the same types of VCs. The virtual concatenation of X VC-4/3 (X=1...256) provides a VC-4/3-Xv. The number of low order VCs that can be virtually concatenated together depends on the higher order VC in which they are transported and is defined according to table 11-9 in G.707. Other types of non-standard virtual concatenation are detailed in [GMPLS-SONET-SDH-EXT]. Each VC has its own Path Overhead (POH). The VC-2/1 K4 POH byte in bit 2 is multi-framed in 32 frames to form a 32 bits string and is used to indicate a frame count and a sequence indicator. The frame count provides a measure of the differential delay (see ITU-T G.707). Each VC2/1 of a VC-2/1-Xv has a fixed unique sequence number in the range of 0 to X-1. The VC-4/3 H4 POH byte is used for the virtual concatenation specific sequence and multi-frame indication. It is more elaborated than for low order VCs and uses a two-stage multi- framing. What is important in the context of GMPLS LBM is that each VC-4/3 has a fixed sequence number in the range of 0 to X-1. These VC sequence numbers will be used by the GMPLS LBM procedures to identify each frame unambiguously in the same virtually concatenated circuit. VCs can be routed and transported individually, even over different multiplex sections, i.e. over different TE link components or over different TE links. They are obvious limitations due to the differential delay between different routes (not in the scope of this specification). GMPLS LBM will provide the same level of flexibility, using and combining multiple LSPs. E. Mannie et. al. Internet-Draft May 2001 4 draft-mannie-ccamp-gmpls-lbm-tdm-00.txt November, 01 3. GMPLS LBM versus LCAS LCAS causes internetworking issues with GMPLS. Having two signaling protocols running in parallel to control the same LSP is not an ideal case. Using LCAS in parallel with GMPLS implies that GMPLS traffic parameters may be modified without the GMPLS control plane being aware of these modifications. However, GMPLS provides natively capabilities to modify traffic parameters of an established LSP. Indeed, the MPLS signaling was originally conceived to allow traffic parameter (bandwidth) modification. LCAS is a signaling protocol restricted to the bandwidth modification at end systems. It doesn't allow setting up and releasing circuits dynamically, and doesn't allow setting up and releasing bandwidth in intermediate nodes. The advantage of using GMPLS is that it provides a complete integrated solution, allowing for a wide range of traffic parameter modifications. Using multiple LSPs to support a single circuit (optional) has the drawback of requiring more signaling but this seems to be the most appropriate way to operate within the context of a global control plane. It provides the advantage that each independent LSP can be protected/restored independently. Note that GMPLS LBM can be first used to modify the bandwidth of a single unique LSP (circuit), without any LSP combination. One drawback of LCAS is that it requires changing the transport plane since new overhead bytes are used. In consequence, new ASICs must be used at both termination ends. On the contrary, GMPLS LBM is done purely in the control plane. It does not require any new ASICs and is backward compatible with the existing hardware. This specification defines how to perform bandwidth modification using the GMPLS signaling. The final result will be almost similar than the one achieved using LCAS, with the advantage of being an integrated solution that doesn't require adaptation of the transport plane. 4. GMPLS LBM Procedures Using a Parallel Circuit This section describes how to modify the bandwidth of a circuit by establishing a new completely bandwidth disjoint circuit and moving the traffic to that new circuit by doing a switchover. This procedure can be done manually or automatically. It uses a simplified version of the make-before-break concept. Note that the concept of "make-before-break" should be better renamed "share-before-break" in this document. In addition, "break" refers more to the LSP status modification in the control plane. E. Mannie et. al. Internet-Draft May 2001 5 draft-mannie-ccamp-gmpls-lbm-tdm-00.txt November, 01 A new disjoint circuit is established first. It can be routed differently from the original circuit and may have completely different traffic parameters. This new circuit reserves its own resources and while the switchover is not done, some bandwidth may be double reserved. This is for instance the only way to change the bandwidth of an SDH LSP from a non-concatenated VC type to a different non- concatenated VC type. For instance, going from a VC-12 to a VC-3 for an IP bandwidth upgrade. Clearly, a VC-12 cannot be shared at the same time with a VC-3 while transporting data. With RSVP-TE, the procedures described in [RSVP-TE] section 4.6.4 could be used but with a FF (Fixed Filter) reservation style instead of a SE (Share Explicit) style (this requires further investigation). An alternative is to use a disjoint source route with a SE style. With CR-LDP, the procedures described in [CRLDP-MODIFY] MUST be used. A new Action Indicator Flag [CRLDP] value is defined hereafter. A disjoint source route can also be used. TBD: indicates modify LSP via a bandwidth disjoint LSP The important point is that the LSP destination must be able to understand that a new LSP is intended to replace an existing one and that this is not just a new independent LSP being setup. This is achieved using the procedures referenced just before. For SONET/SDH, the switchover from the working circuit to the new one is a pure local operation. It can be done very quickly, and certainly faster than 50ms. From that perspective it can be considered as non-service impacting and non-disruptive. 5. GMPLS LBM Procedures Using Virtual Concatenation This section defines simple procedures for SONET/SDH circuit bandwidth modification when virtual concatenation is used. It first defines the procedures to add or remove VCs in a single LSP, and then defines the procedures to combine several LSPs together. A non-concatenated circuit can also be modified to a virtually concatenated circuit (with any number of SPEs/VCs), and vice-versa, by using the procedures defined hereafter. 5.1 Single LSP bandwidth modification This section is only applicable to the standard virtual concatenation as defined by T1X1/ITU-T. Another section deals with non-standard other types of virtual concatenation. SONET/SDH LSP bandwidth modification can only be allowed when the LSP is already set up and active, i.e. modification is not defined E. Mannie et. al. Internet-Draft May 2001 6 draft-mannie-ccamp-gmpls-lbm-tdm-00.txt November, 01 or allowed during the LSP(s) establishment or release. Only bandwidth modification requested by the ingress LSR of the LSP is considered here. The Ingress LSR cannot modify an LSP before a previous modification procedure is completed. When a bandwidth modification is requested, a new (updated) SONET/SDH traffic parameter is send downstream within a Path/Label Request message. This request is explicitly identified as a bandwidth modification request using a special indication mechanism. With RSVP-TE, the procedures for bandwidth modification defined in section 4.6.4 of [RSVP-TE] are used. The SENDER_TEMPLATE and FILTER_SPEC objects carry a modified LSP ID when a Path message with a modified SONET/SDH traffic parameter has to be sent. This allows recognizing that a bandwidth modification is requested. With CR-LDP, the procedures described in [CRLDP-MODIFY] MUST be used. The Action Indicator Flag [CRLDP] of the LSPID TLV indicates an LSP modification. This allows recognizing that a bandwidth modification is requested. If accepted, the same new traffic parameter is sent back to the source also indicating a bandwidth modification indication. This traffic parameter is transported in the FLOWSPEC of a Resv message with RSVP-TE or in the Label Mapping message with CR-LDP. If refused, the previously used SONET/SDH traffic parameter is sent back to the source also indicating a bandwidth modification indication. It allows ensuring that the request for bandwidth modification was well received and treated by the destination. The actual bandwidth allocation is committed when the Resv message flows in the upstream direction. A modified SONET/SDH traffic parameter SHOULD have a different NVC field and MAY have a different MT field. The multiplier field (MT) SHOULD not be used since it is used for a different semantic. All other fields MUST be identical. SPEs/VCs can only be added at the end of an LSP (similarly to LCAS). For instance, when adding Y VC-4s to a VC-4-Xv (where each of the VC-4 is numbered from 0 to X-1), one obtains a VC-4-(X+Y)v with the sequence numbered from 0 to X+Y-1. The number Y of SPEs/VCs to add is given by the following equation: (new NVC * new MT) - (old NVC * old MT). The first new SPE/VC will have a sequence number equals to the sequence number of the previously last VC + 1 (i.e. X). SPEs/VCs can be removed from an LSP but only at the end of that LSP (i.e. starting at SPE/VC sequence number X). When a new traffic parameter is sent requesting less SPEs/VCs, the difference is removed from the end. This is a light limitation in comparison with E. Mannie et. al. Internet-Draft May 2001 7 draft-mannie-ccamp-gmpls-lbm-tdm-00.txt November, 01 LCAS that allows removing SPEs/VCs from anywhere, however this doesn't provide any real interest. The sequence number of each SPE/VC is transported in the corresponding POH according to the SONET/SDH specifications. It is not needed to transport these sequence numbers in the GMPLS signaling, they are implicitly deduced at each end according to the order of operations. When adding or removing SPEs/VCs, the sequence numbers of the other (previous) SPEs/VCs of the same LSP are not modified and stay identical. 5.2 Multiple LSPs combination The reasons to combine multiple LSPs to provide one big SONET/SDH circuit were already explained before. Such a combination requires that all LSPs belonging to the same circuit be clearly identified as belonging to the same group, and be clearly identified as being in a given order. This is achieved by using a Circuit ID and an LSP Sequence Number in the signaling. Obviously, each LSP of the combination may have a different number of SPEs/VCs. All LSPs belonging to the same circuit MUST have the same Circuit ID. All LSPs MUST have a unique LSP sequence number in that Circuit ID, the LSP sequence number MUST be the sequence number of the first SPE/VC of the overall virtually concatenated circuit. This sequence number is redundant information with the SONET/SDH SPE/VC sequence number transported in the POH. This allows a level of consistency checking between the control plane and the transport plane. From the GMPLS control plane point of view, these LSPs are seen as totally independent and being uniquely identified in RSVP-TE by the SESSION object together with the SENDER_TEMPLATE or FILTER_SPEC object. They can be co-routed or not. They can be routed explicitly diversely or not. They can fail separately and be individually protected/restored or not. The GMPLS LBM "application" can be seen as a straightforward application at the top of the control plane, managing individual LSPs made of virtually concatenating VCs, to build a bigger SONET/SDH virtually concatenated circuit. This "application" is only supported at each end of an SONET/SDH circuit without impacting intermediate nodes. All SPEs/VCs corresponding to a new LSP can only be added at the end of the virtually concatenated signal. In that case, the SPE/VC sequence number of the first SPE/VC is the sequence number of the last SPE/VC of the last LSP + 1. When an LSP is removed, for whatever reason, all its SPEs/VCs are removed. In that case, it means that sequence numbers of other SPEs/VCs belonging to the LSPs logically following the removed LSP must be renumbered. The same is done for the LSP sequence numbers. E. Mannie et. al. Internet-Draft May 2001 8 draft-mannie-ccamp-gmpls-lbm-tdm-00.txt November, 01 This is not an issue since all the LSPs are controlled by the same entity. Note that according to the single LSP bandwidth modification procedure defined here before, only the last SPEs/VCs of an LSP can be removed. It results in a multi-LSP configuration that SPEs/VCs can also be removed independently of a complete LSP removal but with the given restriction. All LSPs belonging to the same virtually concatenated signal MUST have the same SONET/SDH traffic parameter, except for the NVC and MT fields. Note however that the use of the multiplier (MT) in that context is not recommended. 5.3 Virtual concatenation of contiguously concatenated signals [GMPLS-SONET-SDH-EXT] allows for the virtual concatenation of contiguously concatenated signals. The procedures for that particular case are for further study and should be part of a non- standard extension to this draft. 5.4 SPE/VC recognition and significance When a modification occurs in a virtually concatenated signal, the receiving end needs to know which SPE/VC is part of the circuit and when the content of each SPE/VC is significant. A SPE/VC is considered as being part of circuit when it is signaled, i.e. when the corresponding Resv/Label Mapping message is sent back to the source. The SPE/VC content is considered as significant when it is received with a non-unequipped indication and a valid sequence number according to the receiving end status. Note that to ensure that in the upstream direction the destination end doesn't send traffic before the source completed the bandwidth modification; the destination end MAY simply wait for a ResvConf to be received with RSVP. Note that the sequence number transported in the POH has a global significance per circuit not per LSP. Since multi-frames are used, the sequence number is considered usable only when the last bit of the multi-framed field has been received. For SDH, indication of an unequipped or equipped signal is given in the C2 byte for VC-4/3 POH, and in the V5 byte for VC-2/VC-12 and VC-11. Note that these bytes provide also the type of client signal mapping being used. 5.4. Extensions encoding E. Mannie et. al. Internet-Draft May 2001 9 draft-mannie-ccamp-gmpls-lbm-tdm-00.txt November, 01 This specification requires the encoding and transport of a Circuit ID and an LSP sequence number for all LSP being established according to the procedures of section 5. Having a Circuit ID even for the single LSP further allows adding additional LSPs to that circuit. A new Circuit ID object/TLV is defined to identify all LSPs belonging to the same SONET/SDH circuit. For RSVP-TE, one new SENDER_TEMPLATE class object is defined and uses a new C-Type (TBA), and one new FILTER_SPEC class object is defined and uses a new C-Type (TBA). In both cases the same object format is used and is defined hereafter. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Circuit ID field: This is a unique Circuit ID number, generated by the source. It is unique in the context of the source and does not change during the lifetime of the circuit. LSP Sequence Number field: This is a unique sequence number in the context of the Circuit ID. It allows ordering the LSP in the SONET/SDH virtually concatenated signal. Numbering starts at 0. For CR-LDP, a new CircuitID TLV is defined and the use of LSPID TLV is mandatory. The format of the CircuitID TLV is defined hereafter. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Type (TBA) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields of that TLV have the same definition as in the RSVP-TE case. 6. GMPLS LBM Procedures with Contiguous Concatenation This section is for further study but the principles could be based on the following ideas: E. Mannie et. al. Internet-Draft May 2001 10 draft-mannie-ccamp-gmpls-lbm-tdm-00.txt November, 01 The concept of make-before-break defined in MPLS can also be used to support bandwidth modification of continuously concatenated signals in the same way as with the single LSP bandwidth modification with virtual concatenation. However, in that case multiple LSPs cannot be combined. A non-concatenated circuit can also be modified to a contiguously concatenated circuit (with any number of SPEs/VCs), and vice- versa, by using the procedures defined hereafter. When increasing the bandwidth of a circuit, it works only if the right number of free SPEs/VCs can be found directly before the beginning of the circuit, or after the end of the circuit. This is unlikely to happen in most of the cases. When decreasing the bandwidth of a circuit, it works in all cases. Note that in contrary to virtual concatenation, there is one single POH. There is of course no SPE/VC sequence number. By analyzing the frame overhead (pointers) one can discover how many SPEs/VCs are contiguously concatenated in one SONET/SDH frame. The new number of concatenated SPEs/VCs must match what was advertised in the traffic parameters. For instance, a received SDH STM-64 frame can contain a VC-4-4c, while a next frame can contain a VC-4-16c starting at the same place as the VC-4-4c and thus occupying the same first VC-4 spaces. This process is not service impacting or disruptive. A modified SONET/SDH traffic parameter SHOULD have a different NCC field and MAY have a different MT field. The RCC field may indicate a different type of contiguous concatenation. The multiplier field (MT) SHOULD not be used since it is used for a different semantic. All other fields MUST be identical. 7. SONET/SDH Traffic parameters The GMPLS extensions for SONET/SDH [GMPLS-SONET-SDH] specify how the SONET/SDH traffic parameters are encoded for both RSVP-TE and CR-LDP. For RSVP-TE, the SONET/SDH traffic parameters are carried in the SONET/SDH SENDER_TSPEC and FLOWSPEC objects. The same format is used for both objects. There is no Adpsec. For CR-LDP, the SONET/SDH traffic parameters are carried in the new SONET/SDH Traffic Parameters TLV. GMPLS LBM explicitly allows the value of the traffic parameters to change over time. A modified SONET/SDH traffic parameter indicates the complete traffic parameters of the circuit and not a delta. The delta computation is simply done by comparing the fields. E. Mannie et. al. Internet-Draft May 2001 11 draft-mannie-ccamp-gmpls-lbm-tdm-00.txt November, 01 8. Acknowledgments Valuable comments and input were received from a number of folks. 9. Security Considerations This draft introduces no new security considerations to [GMPLS- SONET-SDH]. 10. References [GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - CR-LDP Extensions", Internet Draft, draft-ietf-mpls-generalized-cr-ldp-04.txt, July 2001. [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - Signaling Functional Description", Internet Draft, draft-ietf-mpls-generalized-signaling-06.txt, October 2001. [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - RSVP-TE Extensions", Internet Draft, draft-ietf-mpls-generalized-rsvp-te-05.txt, October 2001. [GMPLS-ARCH] E. Mannie Editor, "GMPLS Architecture", Internet Draft, draft-ietf-ccamp-gmpls-architecture-00.txt, June 2001. [GMPLS-SONET-SDH] E. Mannie Editor, "GMPLS Extensions for SONET and SDH Control", Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh-02.txt, October 2001. [GMPLS-SONET-SDH-EXT] E. Mannie Editor, "GMPLS Extensions to Control Non-Standard SONET and SDH Features", Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt, October 2001. [CRLDP-MODIFY] J. Ash et al, "LSP Modification Using CR-LDP", Internet Draft, draft-ietf-mpls-crlsp-modify-03.txt, March 2001. [RSVP-TE] Swallow et al, " RSVP-TE: Extensions to RSVP for LSP Tunnels", Internet Draft, draft-ietf-mpls-rsvp-lsp- tunnel-09.txt, August 2001. [CRLDP] Bilel Jamoussi, Editor, "Constraint-Based LSP Setup using LDP", Internet Draft, draft-ietf-mpls-cr-ldp- E. Mannie et. al. Internet-Draft May 2001 12 draft-mannie-ccamp-gmpls-lbm-tdm-00.txt November, 01 05.txt, February 2001. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services," RFC 2210, September 1997. 11. Authors' Addresses Eric Mannie EBONE Terhulpsesteenweg 6A 1560 Hoeilaart - Belgium Phone: +32 2 658 56 52 Mobile: +32 496 58 56 52 Fax: +32 2 658 51 18 Email: eric.mannie@ebone.com Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: Dimitri.Papadimitriou@alcatel.be E. Mannie et. al. Internet-Draft May 2001 13