CCAMP Working Group Eric Mannie (KPNQwest) Internet Draft D.Papadimitriou (Alcatel) Expiration Date: September 2002 L.Ong (Ciena) March 2002 GMPLS LSP Bandwidth Modification (LBM) for SONET/SDH draft-mannie-ccamp-gmpls-lbm-tdm-02.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. connection) being requested. Such a connection can be requested unidirectional or bi-directional. Dynamically changing the bandwidth allocated for a SONET/SDH connection is very useful for instance, when Ethernet traffic is transported over SONET/SDH connections. According to the demand, the size of a concatenated SONET/SDH connection can be modified dynamically without having to reestablish a new connection, and potentially to interrupt the service. SONET/SDH, bandwidth modification can be indeed achieved in very different ways. It can be realized by establishing another E. Mannie et. al. Internet-Draft - September 2002 1 draft-mannie-ccamp-gmpls-tdm-lbm-02.txt March 02 connection between the same source and destination with different characteristics (e.g. signal type) and then by switching the traffic to the newly established connection by performing a switchover. At the other end of the spectrum, bandwidth modification can be done by dynamically adding or removing SPEs/VCs to a connection using the concept of virtual concatenation (or potentially contiguous concatenation). This would ideally be achieved in a non-disruptive way while avoiding double counting (i.e. double reservation) the resources while modifying the bandwidth by using for instance the concept of make-before-break. The current proposal focuses among other on this last case where only differential capacity is added (or removed) to the connection. In practice, bandwidth modification is mainly achievable when virtual concatenation is used since SPEs/VCs donĘt need to be contiguous: they are transported individually and can even be routed independently. This could also be achieved when using contiguous concatenation but in practice this approach is much less likely to happen since a bandwidth increase requires additional free SPEs/VCs physically contiguous at each interface traversed by the connection. 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 elevates this current GMPLS limitation by allowing a SONET/SDH circuit to be made of several independent connections (i.e. LSPs). GMPLS signalling currently supports simultaneous setup of multiple SPEs/VCs in a single setup request. This requires the SPEs/VCs to be routed through the same Line/MS section. This document extends the GMPLS procedures to allow separate setup of multiple LSPs, possibly with disjoint routing, to be coordinated at the endpoints. 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 Related Efforts: T1X1 and ITU-T have defined in ITU-T G.7042 (also known as G.lcas) a protocol called Link Capacity Adjustment Scheme (LCAS) for virtual concatenated (group) signals for SONET/SDH and G.709 OTN (Optical Transport Networks), independently of any distributed control plane. This signalling protocol transported in-band in the Path Overhead (POH), for instance in SONET/SDH. 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 E. Mannie et. al. Internet-Draft - September 2002 2 draft-mannie-ccamp-gmpls-tdm-lbm-02.txt March 02 experience 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. The same applies for SONET, where LCAS is defined for high order STS-1-Xv/STS-3c-Xv and low-order VTn-Xv SPE (n = 1.5, 2, 3, 6). Current scope and coverage: This document defines LSP Bandwidth Modification (LBM) procedures and extensions for GMPLS using either virtual concatenation or contiguous concatenation. It defines among other a combination of the signalling provided by GMPLS and LCAS at the control and transport plane, respectively. Note the current version focuses on SONET/SDH and will in a future release cover G.709 Optical Transport Networks (OTN). Similarly to GMPLS, this document covers bandwidth modification of unidirectional LSPs and bi-directional symmetric LSPs. Bi- directional asymmetric LSPs setup is not supported by the current GMPLS Signalling specification. In this context, the current proposal allows for SONET/SDH bandwidth modification being requested only by the initiator (source) of a circuit. A next version might cover destination initiated bandwidth modification. It could also be extended to cover modification of other connection attributes than the bandwidth, like link protection/restoration characteristics. In brief, this document specifies the following bandwidth modification (i.e. increase/decrease) scenarios: Scenario 1: GMPLS LBM without Virtual Concatenation referred to as LBM using parallel LSP Scenario 2: GMPLS without LCAS but with Virtual Concatenation - with Single LSP Bandwidth Modification - with Multiple LSP Combination (within a Circuit) Scenario 3: GMPLS with LCAS running in sequence using GMPLS for LSP provisioning and LCAS for e2e in-band signalling 2. SONET/SDH Concatenation 2.1 SDH Virtual and Contiguous Concatenation Section 11 of G.707 (April 2000) recommendation defines VC contiguous and virtual concatenation. Contiguous concatenation maintains the bandwidth contiguous through the whole network, while virtual concatenation breaks the bandwidth into individuals VCs, transports and routes these VCs individually from the source and then recombines them at the path termination. Virtual concatenation E. Mannie et. al. Internet-Draft - September 2002 3 draft-mannie-ccamp-gmpls-tdm-lbm-02.txt March 02 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). - Virtual concatenation is defined for VC-4s, VC-3s, VC-2s, VC-12s and VC-11s but all the 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. There are limitations due to the differential delay between different routes (outside of the scope of this document). GMPLS LBM provides the same level of flexibility, using and combining multiple LSPs. 2.2 SONET Virtual and Contiguous Concatenation ANSI T1.105 recommendation defines VC contiguous and virtual concatenation. Contiguous concatenation maintains the bandwidth contiguous through the whole network, while virtual concatenation breaks the bandwidth into individuals STS SPEs, transports and routes these STS SPEs 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 STS-1/STS-3c SPEs to provide a STS-(3*X)c SPE (X=1, 4, 16, 64, 256) - Virtual concatenation is defined for STS-1s, STS-3cs and VTn SPEs E. Mannie et. al. Internet-Draft - September 2002 4 draft-mannie-ccamp-gmpls-tdm-lbm-02.txt March 02 (n = 1.5, 2, 3, 6) but all the STS/VT SPEs belonging to a virtually concatenated circuit must be of the same type. The virtual concatenation of X STS-1/STS-3c (X=1,...,256) provides a STS-1-Xv/STS-3c-Xv SPE. The number of low order VTn SPEs (n = 1.5, 2, 3, 6) that can be virtually concatenated together depends on the higher order STS-1/STS-3c SPE in which they are transported as defined according to Table 8 of ANSI T1.105. Each VT/STS SPE has its own Path Overhead (POH): - For low order VT SPEs: the VTn Z7 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 ANSI T1.105). Each VTn SPE of a VTn-Xv SPE has a fixed unique sequence number in the range of 0 to X-1. - For high order STS SPEs: the STS-1/STS-3c H4 POH byte is used for the virtual concatenation specific sequence and multi-frame indication. It uses a two-stage multi-framing. As for SDH, the important point in the context of GMPLS LBM is that each STS- 1/STS-3c SPE has a fixed sequence number in the range of 0 to X-1. These sequence numbers will be used by the GMPLS LBM procedures to identify each frame unambiguously in the same virtually concatenated circuit. As for SDH, VTs/STS SPEs can be routed and transported individually, even over different line sections, i.e. over different TE link components or over different TE links. 3. GMPLS LBM and LCAS Link Capacity Adjustment Scheme (LCAS) recommendation [LCAS] details the procedure to add (or remove) a VC-4/VC-3 into a VC-n-Xv group (n = 3, 4) and to add (or remove) a VC-11/VC-12/VC-2 into a VC-m-Xv group (m = 11, 12, 2). LCAS is defined as an end-to-end signalling protocol transported over the H4 overhead (for HOVC) and K4 overhead (for LOVC). The same applies in SONET for high order STS-1-Xv/STS- 3c-Xv and low-order VTn-Xv SPE (n = 1.5, 2, 3, 6) signalling being transported over H4 and Z7 POH, respectively. Running GMPLS at the control plane level and LCAS at the transport plane level implies to clearly define the interactions between these protocols. LCAS is an end-to-end (i.e. PTE-to-PTE) signalling protocol enabling at end systems both bandwidth modification and setting/releasing connections belonging to the same circuit, provisioned through Element/Network Management Systems (EMS/NMS) or any distributed control plane. However, LCAS doesnĘt provide setting up and releasing connections at intermediate nodes. This means that LCAS must be combined with an EMS/NMS system or any distributed control plane in order to offer a dynamic connection setup throughout the network. Therefore, using LCAS in parallel with current GMPLS signalling implies that GMPLS traffic parameters may be modified without the GMPLS control plane being aware of these modifications. On the other hand, since MPLS-TE signalling was originally conceived to allow E. Mannie et. al. Internet-Draft - September 2002 5 draft-mannie-ccamp-gmpls-tdm-lbm-02.txt March 02 traffic parameter (bandwidth) modification, GMPLS can provide native capabilities to modify traffic parameters of an established LSP. This document defines among others, how to achieve LSP (i.e. connection) bandwidth modification using GMPLS signalling and LCAS or even with any other appropriate mechanism providing the equivalent capability) at the transport plane level. It also specifies bandwidth modification when using multiple LSPs to support a single circuit. This approach has the drawback of requiring more signalling but seems to be more appropriated when operating within the context of a global control plane. It provides the advantage that each LSP can be routed independently and 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. 4. GMPLS LBM Procedures Using a Parallel Connection This section describes how to modify the bandwidth of a connection by establishing a new completely bandwidth disjoint connection and moving the traffic to the newly established connection by doing a switchover at the end-points. This procedure can be performed manually or automatically. It also uses a simplified version of the make-before-break concept. A new disjoint connection is first established. It can be routed differently from the original connection and may have completely different traffic parameters. This new connection reserves its own resources and before performing the switchover, 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. An example is when going from a VC-3 to a VC-4 for an IP/MPLS bandwidth upgrade. This situation is depicted in the following figure: Step 1: Make ----------- Working ----------- | |VC-3 |-----------------| VC-3| | Working active | 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 E. Mannie et. al. Internet-Draft - September 2002 6 draft-mannie-ccamp-gmpls-tdm-lbm-02.txt March 02 ----------- Break (GMPLS) ----------- | |VC-3 |<--------------->| VC-3| | | PTE |----- Working -----| PTE | | |VC-4 |-----------------| VC-4| | Working active ----------- ----------- 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 major point is that the LSP destination must be able to understand that 1) a new LSP is intended to replace an existing LSP and 2) this newly setup LSP is not independent of the existing one. This is achieved using the mechanism explained here above. For SONET/SDH, the switchover from the working connection to the new one is an endpoint operation only. This operation can be performed very quickly within the 50ms constraint. From this perspective, this mechanism can be considered as a non-disruptive bandwidth service modification. 5. GMPLS LBM Procedures Using Virtual Concatenation This section defines the procedures for SONET/SDH bandwidth modification when virtual concatenation is used. It first defines the procedures to add or remove VCs in a single LSP (Section 5.1), and then the one enabling to combine several LSPs together (Section 5.2). 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 shall not modify an LSP before a previous modification procedure is completed. When a bandwidth modification is requested, an 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. E. Mannie et. al. Internet-Draft - September 2002 7 draft-mannie-ccamp-gmpls-tdm-lbm-02.txt March 02 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 indicating a bandwidth modification of a unidirectional or a bi-directional LSP. 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. It allows ensuring that the request for bandwidth modification was well received and treated by the destination without commitment of the requested modification. Note that 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. 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[0] = 0 and VC-4[1] = 1 New Traffic Parameters: ST = VC-4 - NVC = 4 - MT = 1 (ADD 2 VC-4) Sequence: VC-4[2] = 2 and VC-4[3] = 3 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 updated circuit and not a delta. E. Mannie et. al. Internet-Draft - September 2002 8 draft-mannie-ccamp-gmpls-tdm-lbm-02.txt March 02 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-1). When a new traffic parameter is sent requesting less SPEs/VCs, the difference is removed from the end of the sequence. This is a limitation in comparison with LCAS that allows removing any SPEs/VCs component (independently of its positions within the sequence). 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 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 larger 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 as being in a given order. Defining an additional Circuit ID and an LSP Sequence Number in GMPLS signalling [GMPLS-SIG] enables to achieve this. 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 a redundant information with respect to 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. Therefore, in this context, the GMPLS LBM "application" can be considered as a straightforward application at the top of the control plane, managing individual LSPs made of virtually concatenated VCs to build a larger SONET/SDH virtually concatenated circuit. This "application" is only supported at each end of an SONET/SDH circuit without impacting intermediate nodes. E. Mannie et. al. Internet-Draft - September 2002 9 draft-mannie-ccamp-gmpls-tdm-lbm-02.txt March 02 All SPEs/VCs corresponding to a new LSP can only be added at the end of the virtually concatenated signal sequence. 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 initiated 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 at all 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 for HOVC/STS SPE 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 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. 5.4 Combining GMPLS LBM with LCAS This section describes a sequential combination of GMPLS and LCAS. In brief, the proposed mechanism runs GMPLS for LSP provisioning between end-points, then activation of the additional HOVC/STS SPE (or LOVC/VT SPE) component using LCAS end-to-end signalling and finally optional confirmation at the control plane level when requesting bandwidth modification of bi-directional LSPs. E. Mannie et. al. Internet-Draft - September 2002 10 draft-mannie-ccamp-gmpls-tdm-lbm-02.txt March 02 The detailed mechanism can be described as follows: 1. Path Message/Label Request message sent from Source to Destination indicating the new Traffic Parameter values i.e. NVC and MT together with 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 using the same Admin Status flag. Notice that the 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 bandwidth increase/decrease is requested for a unidirectional LSP: 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 bandwidth increase/decrease is requested for a bi-directional LSP: 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 messages are ignored by the non-supporting end) and bandwidth increase is requested for bi-directional LSP: 3c. The source sends the ResvConf back to the destination indicating the bi-directional successful establishment and the source side can start to use the new bandwidth 4c. On receipt of the ResvConf the destination side can start to to use the new bandwidth. 5.5 GMPLS Signalling Extensions This memo requires the encoding and transport of a Circuit ID and an LSP Sequence Number for all LSPs being established according to the procedures of Section 5.2. Having a Circuit ID even for a single LSP circuit further allows adding LSPs to this circuit. A new Circuit ID object/TLV is defined to identify all LSPs belonging to the same SONET/SDH circuit inside of which the Sequence Number identifies each (component) LSP. 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). E. Mannie et. al. Internet-Draft - September 2002 11 draft-mannie-ccamp-gmpls-tdm-lbm-02.txt March 02 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. In the current version, when used this field MUST be non-zero. - LSP Sequence Number field (16 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 with Contiguous Concatenation A non-concatenated circuit could be modified to a contiguously concatenated circuit (with any number of SPEs/VCs), and vice-versa. However the corresponding behavior in the transport plane is not standardized today. This kind of LSP bandwidth modification would be useful to consider as further investigation. This approach would imply some issues briefly introduced hereafter. When increasing the bandwidth of a circuit, it could work 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 could work in all cases. For instance, a received SDH STM-64 frame could contain a VC-4-4c, while a next frame could contain a VC-4-16c starting at the same place as the VC-4-4c and thus occupying the same first VC-4 spaces. As opposed to virtual concatenation, there is one single POH and there is of no SPE/VC sequence number. Therefore, the new number of concatenated SPEs/VCs MUST match the one advertised in the traffic parameters as indicated in the NCC field (see [GMPLS-SONET-SDH]). The concept of make/share-before-break defined in MPLS could 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 can not be combined. 7. Acknowledgments The authors would like to thank J.Jones (Alcatel), G.Grammel (Alcatel), A.Bellato (Alcatel) and S.Ansorge (Alcatel) for their useful input and comments. Valuable comments and input were also E. Mannie et. al. Internet-Draft - September 2002 12 draft-mannie-ccamp-gmpls-tdm-lbm-02.txt March 02 received from A.Geyssens, M.Moelants, X.Neerdaels and P.Noel and F.Yin. 8. Security Considerations This draft introduces no new security considerations to [GMPLS- SONET-SDH]. 9. References [GMPLS-LDP] Berger, L. (Editor), "Generalized MPLS Signaling - CR-LDP Extensions", Internet Draft, draft-ietf-mpls- generalized-cr-ldp-05.txt, November, 2001. [GMPLS-SIG] Berger, L. (Editor), "Generalized MPLS ū Signaling Functional Description", Internet Draft, draft-ietf- mpls-generalized-signaling-07.txt, November 2001. [GMPLS-RSVP] Berger, L. (Editor), "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-02.txt, February 2002. [GMPLS-SONET-SDH] Mannie, E. (Editor), "GMPLS Extensions for SONET and SDH Control", Internet Draft, draft-ietf-ccamp- gmpls-sonet-sdh-03.txt, February 2002. [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-01.txt, February 2002. [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. 10. Authors' Addresses Eric Mannie (KPNQwest) Terhulpsesteenweg 6A 1560 Hoeilaart, Belgium Phone: +32 2 658-5652 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 - September 2002 13