CCAMP Working Group Eric Mannie (Ebone) Internet Draft D. Papadimitriou (Alcatel) Expiration Date: August 2002 J. Jones (Alcatel) L. Ong (Ciena) February 2002 GMPLS LSP Bandwidth Modification (LBM) for SDH/SONET draft-mannie-ccamp-gmpls-lbm-tdm-01.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." 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 document defines how GMPLS can be used to dynamically modify the bandwidth of a TDM circuit. It focuses first on SONET/SDH and intend to cover other technologies in a further release. This document also defines how to use multiple differently routed LSPs to build a single SONET/SDH virtually concatenated circuit. Each LSP can be recovered (i.e. protected or restored) individually. 1. Introduction Extensions to GMPLS are defined to control SONET/SDH networks in [GMPLS-SONET-SDH]. They specify the 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. Dynamically changing the bandwidth allocated for a SONET/SDH circuit is very useful for instance, when Ethernet traffic is transported E. Mannie et. al. Internet-Draft - August 2002 1 draft-mannie-ccamp-gmpls-tdm-lbm-01.txt FebÆ02 over SONET/SDH circuits. 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. 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 for instance, the concept of make-before-break. The current proposal focuses on this last case where only differential capacity is added (or removed) to the circuit. In practice, bandwidth modification is achievable when virtual concatenation is used since SPEs/VCs donÆt need to be contiguous, are transported individually and can even be routed independently. This could also be achieved as well when contiguous concatenation is used but is in practice much less likely to happen since a bandwidth increase requires additional free SPEs/VCs physically contiguous at each interfaceÆs node traversed by the circuit. Moreover, as currently defined, GMPLS only allows the SPEs/VCs components belonging to a virtually concatenated circuit to be co- routed through the same line/multiplex section. This contribution removes this limitation 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 document). T1X1 and ITU-T Efforts: ----------------------- T1X1 and ITU-T are standardizing a similar concept for SONET and SDH but also G.709 OTN (Optical Transport Networks), independently of any distributed control plane and for virtual concatenation only. They defined a signalling protocol transported in-band in the overhead, for instance in SONET/SDH, this protocol is transported in the Path Overhead (POH). This protocol is defined in ITU-T Recommendation G.7042 (former G.lcas) and called Link Capacity Adjustment Scheme (LCAS) for virtual concatenated (group) signals. LCAS allows increasing or decreasing the capacity of a virtual E. Mannie et. al. Internet-Draft - August 2002 2 draft-mannie-ccamp-gmpls-tdm-lbm-01.txt FebÆ02 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. Current scope and coverage: --------------------------- This document defines LSP Bandwidth Modification (LBM) procedures and extensions for GMPLS using either virtual concatenation or contiguous concatenation. It also proposes a combination of the signalling provided by GMPLS and LCAS at the control and transport plane, respectively. Note it first focuses on SONET/SDH and will later cover G.709 with the same approach in a next version. Similarly to GMPLS, this document 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. The current proposal allows for 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. It can also 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. 2. SONET/SDH Virtual and Contiguous Concatenation This section 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: E. Mannie et. al. Internet-Draft - August 2002 3 draft-mannie-ccamp-gmpls-tdm-lbm-01.txt FebÆ02 - 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). - Virtual concatenation is defined for VC-4s, VC-3s, VC-2s, VC-12s and VC-11s but VCs belonging to a virtually concatenated circuit must be of the same type. 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. Each VC has its own Path Overhead (POH): - For low order VC: 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 VC-2/1 of a VC-2/1-Xv has a fixed unique sequence number in the range of 0 to X-1. - For high order VC: the VC-4/3 H4 POH byte is used for the virtual concatenation specific sequence and multi-frame indication. It is more elaborate 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 document). GMPLS LBM will provide the same level of flexibility, using and combining multiple LSPs. 3. GMPLS LBM and LCAS Link Capacity Adjustment Scheme (LCAS) recommendation [LCAS] details the procedure to add (or remove) a VC-4/VC-3 from a VC-4-xV/VC-3-xV group. LCAS is defined as an end-to-end signalling protocol transported over the H4 overhead (for HOVC/STS SPE) and K4 overhead (for LOVC/VT) using additional MFI (multi-frame indicator) and SEQ (sequence indicator) values than the one defined for Virtual Concatenated signals. When running GMPLS at the control plane level and LCAS at the transport level, since the latter is an end-to-end signalling protocol, we have to clearly define the function fulfilled by each of these signalling protocols. LCAS is an end-to-end (i.e. PTE-to-PTE) signalling protocol enabling the bandwidth modification at end systems and setting up and releasing circuits provisioned and configured through Network Management Systems (NMS). However, LCAS doesn't apply to setting up E. Mannie et. al. Internet-Draft - August 2002 4 draft-mannie-ccamp-gmpls-tdm-lbm-01.txt FebÆ02 and releasing bandwidth at intermediate nodes. This means that LCAS must be combined with an NMS system in order to offer a dynamic connection setup throughout the network. Therefore, the advantage of using GMPLS is that it provides a complete integrated solution, allowing for a wide range of traffic parameter modifications. 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 native capabilities to modify traffic parameters of an established LSP since MPLS-TE signalling was originally conceived to allow traffic parameter (bandwidth) modification. Using multiple LSPs to support a single circuit (optional) has the drawback of requiring more signalling 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. This document defines the concept underlying LSP (i.e. connection) bandwidth non-disruptive modification using GMPLS signalling. Compared to an LCAS only solution (combined or not with EMS/NMS) it provides the advantage of being an integrated solution. At the transport plane level this solution can be combined with LCAS or any other appropriate mechanism providing the equivalent capability. 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 in the context of this document, the concept of "make- before-break" should be better renamed "share-before-break". In addition, "break" refers more to the LSP status modification in the control plane than to circuit connection changes in the transport plane. 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 before the switchover is 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-3 to a VC-4 for an IP/MPLS bandwidth upgrade. Clearly, a VC-3 (on an STM-0) cannot be shared at the same time with a VC-4 (on an STM-1) while E. Mannie et. al. Internet-Draft - August 2002 5 draft-mannie-ccamp-gmpls-tdm-lbm-01.txt FebÆ02 transporting data. This situation is depicted in the following figure: Step 1: Make ----------- Working ----------- Working active | |VC-3 |-----------------| VC-3| | | PTE |----- Make (GMPLS) -----| PTE | | |VC-4 |<--------------->| VC-4| | ----------- ----------- Step 2: Share ----------- Working ----------- | |VC-3 |<--------------->| VC-3| | Working active | PTE |----- Working -----| PTE | | |VC-4 |<--------------->| VC-4| | Working standby ----------- ----------- Step 3: Break ----------- Break (GMPLS) ----------- | |VC-3 |<--------------->| VC-3| | | PTE |----- Working -----| PTE | Working active | |VC-4 |-----------------| VC-4| | ----------- ----------- 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 for this purposes. A disjoint source route can also be used. 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 endpoint operation. It can be done very quickly and certainly within the 50ms constraint. 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. E. Mannie et. al. Internet-Draft - August 2002 6 draft-mannie-ccamp-gmpls-tdm-lbm-01.txt FebÆ02 5.1 Single LSP bandwidth modification This section is only applicable to the standard virtual concatenation as defined by T1X1/ITU-T (see [T1.105] and [G.707], respectively). SONET/SDH LSP bandwidth modification can only be allowed when the LSP is already set up and active, i.e. modification is not defined 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 sent downstream within a Path/Label Request message. This request is explicitly identified as a bandwidth modification request using a specific 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 SENDER_TSPEC objects carry respectively a modified LSP ID and a modified SONET/SDH traffic parameter within the Path message sent from the source LSR (i.e. head-end PTE) to the destination LSR (i.e. tail-end PTE). 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. Subsequently, the following alternative can be considered: - If accepted, the same new traffic parameter is sent back to the source also indicating a bandwidth modification. This traffic parameter is transported in the FLOWSPEC of the 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/Label Mapping 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 this field has a different semantic. All other fields MUST be identical. SPEs/VCs can only be added at the end of an LSP. 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. E. Mannie et. al. Internet-Draft - August 2002 7 draft-mannie-ccamp-gmpls-tdm-lbm-01.txt FebÆ02 The number Y of SPEs/VCs to add is given by the following equation: ABS[(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). Example: Old Traffic Parameters: ST = VC-4 û NVC = 2 û MT = 1 (VC-4-2v) Sequence: VC-4[1] = 0 and VC-4[2] = 1 New Traffic Parameters: ST = VC-4 û NVC = 4 û MT = 1 (ADD 2 VC-4) Sequence: VC-4[3] = 2 and VC-4[4] = 3 Such that the (new NVC * new MT) - (old NVC * old MT) is verified. GMPLS LBM explicitly allows the value of the traffic parameters to change over time. 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. 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 LCAS that allows removing SPEs/VCs from anywhere, however this doesn't provide significant benefit. Note: 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 signalling, 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 GMPLS signalling [GMPLS-SIG]. Obviously, each LSP of the combination may have a different number of SPEs/VCs. The following rules are defined together with the introduction of the Circuit ID and the LSP Sequence Number: - 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 E. Mannie et. al. Internet-Draft - August 2002 8 draft-mannie-ccamp-gmpls-tdm-lbm-01.txt FebÆ02 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 concatenated 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. This implies 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. However, 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 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 valid. 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 specific indication in the POH (it can also be located in the H4 POH byte as defined by LCAS) and a valid sequence number according to the receiving end status. The sequence number transported in the POH has a global E. Mannie et. al. Internet-Draft - August 2002 9 draft-mannie-ccamp-gmpls-tdm-lbm-01.txt FebÆ02 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. Note: 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. 5.4 Combining GMPLS LBM with LCAS This section describes a sequential combination of GMPLS and LCAS LCAS. In brief, the proposed mechanism runs GMPLS for LSP provisioning between end-points, then activation of the additional VC/STS component using LCAS end-to-end signalling and finally optional confirmation at the control plane level when requesting bi- directional bandwidth increase. The detailed mechanism can be described as follows: 1. Path Message/Label Request message from Source to Destination indicating the incremental Traffic Parameter values i.e. NVC and MT and the capability of the Source to support of LCAS or not (by using a specific flag in the Admin_Status object/TLV for instance) 2. Resv/Label Mapping Message sent back as described in Section 5.3 in addition to the LCAS capability support by the receiver. Same rules as the one defined for the Admin Status object/TLV are used for that purpose. IF LCAS is supported by both ends and unidirectional bandwidth increase is requested: 3a. LCAS end-to-end signalling protocol used to exchange the H4 CTRL messages 4a. Trigger the H4 NORM value and use the allocated bandwidth IF LCAS is supported by both ends and bidirectional bandwidth increase is requested: 3b. LCAS end-to-end signalling protocol used to exchange the H4 CTRL messages 4b. Trigger the H4 NORM value and use the allocated bandwidth 5b. Source may send a ResvConf message to the destination in order to prevent the destination from sending data before the source completes the bandwidth modification IF LCAS NOT supported by at least one end (LCAS messaged are ignored by the non-supporting end) and uni or bi-directional bandwidth increase is requested: 3c. The source sends the ResvConf back to the destination indicating the bidirectional successful establishment and the source side can start to use the new channel 4c. On receipt of the ResvConf the destination side can start to to use the new channel. E. Mannie et. al. Internet-Draft - August 2002 10 draft-mannie-ccamp-gmpls-tdm-lbm-01.txt FebÆ02 5.5 GMPLS Extensions encoding This memo 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 a single LSP circuit further allows adding LSPs to that circuit. A new Circuit ID object/TLV is defined to identify all LSPs belonging to the same SONET/SDH circuit where each LSP is identified by a sequence number. 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). For CR-LDP, a new Circuit ID TLV is defined and the use of LSPID TLV is mandatory. In both cases this Object/TLV includes the following fields: - Circuit ID field (32 bits) 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 (32 bits) 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. 6. GMPLS LBM Procedures with Contiguous Concatenation This section is for further study but the procedure should at least support the following capabilities. A non-concatenated circuit can be modified to a contiguously concatenated circuit (with any number of SPEs/VCs), and vice-versa, by using the procedures defined hereafter. Typically this function is provided when using AUG flexible multiplexing allowing to increase change a N x AUG-1 to an AUG-N (with N = 4, 16, 64, 256). 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. 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. E. Mannie et. al. Internet-Draft - August 2002 11 draft-mannie-ccamp-gmpls-tdm-lbm-01.txt FebÆ02 As opposed to virtual concatenation, there is one single POH and there is of course no SPE/VC sequence number. Therefore, 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. Nevertheless, the concept of make/share-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. 7. Acknowledgments Valuable comments and input were received from Alexandre Geyssens, Michael Moelants, Xavier Neerdaels and Philippe Noel and Fuhua Yin. 8. Security Considerations This draft introduces no new security considerations to [GMPLS- SONET-SDH]. 9. References [GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - CR-LDP Extensions", Internet Draft, draft-ietf-mpls- generalized-cr-ldp-05.txt, November, 2001. [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS û Signaling Functional Description", Internet Draft, draft-ietf- mpls-generalized-signaling-07.txt, November 2001. [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - RSVP-TE Extensions", Internet Draft, draft-ietf- mpls-generalized-rsvp-te-06.txt, November 2001. [GMPLS-ARCH] Mannie, E. (Editor), "GMPLS Architecture", Internet Draft, draft-ccamp-ietf-gmpls-architecture-01.txt, November 2001. [GMPLS-SONET-SDH] Mannie, E. (Editor), "GMPLS Extensions for SONET and SDH Control", Internet Draft, draft-ietf-ccamp- gmpls-sonet-sdh-02.txt, October 2001. [GMPLS-SONET-SDH-EXT] Mannie, E. (Editor), "GMPLS Extensions to Control Non-Standard SONET and SDH Features", Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh- extensions-00.txt, October, 2001. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. E. Mannie et. al. Internet-Draft - August 2002 12 draft-mannie-ccamp-gmpls-tdm-lbm-01.txt FebÆ02 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services," RFC 2210, September 1997. 10. Authors' Addresses Eric Mannie EBONE Terhulpsesteenweg 6A 1560 Hoeilaart - Belgium Phone: +32 2 658 56 52 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 - August 2002 13