CCAMP Working Group Eric Mannie (Consulting) Internet Draft Dimitri Papadimitriou (Alcatel) Expiration Date: May 2003 Lyndon Ong (Ciena) November 2002 GMPLS LSP Bandwidth Modification (LBM) for SONET/SDH draft-mannie-ccamp-gmpls-lbm-tdm-04.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." Abstract This document defines how GMPLS can be used to dynamically modify the bandwidth of a TDM LSP. It focuses first on SONET/SDH and intends to cover other switching 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 where each component LSP can be subsequently recovered (i.e. protected or restored) individually. 1. Introduction Generalized MPLS (GMPLS) extensions to control SONET/SDH networks are defined 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 as unidirectional or bi-directional. E. Mannie et. al. Internet-Draft û May 2003 1 draft-mannie-ccamp-gmpls-tdm-lbm-04.txt November 2002 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 achieved in very different ways. If not using virtual concatenation it can be realized by establishing another 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. Using virtual concatenation allows the connection bandwidth to be modified by adding and removing SPEs/VCs to a connection consisting of multiple SPEs/VCs. Use of LCAS further allows this to be done without disruption of service. This would ideally be achieved while avoiding double counting (i.e. double reservation) the resources while modifying the bandwidth by using for instance the concept of make-before-break. In practice, bandwidth modification is most efficiently done 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 to be allocated at each interface traversed by the connection during the switchover. GMPLS signalling currently supports simultaneous setup of multiple SPEs/VCs in a single setup request. This requires the SPEs/VCs belonging to a single circuit to be routed through the same Line/Multiplex 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, as is desired for virtual concatenation. 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: ------------------------------ Both have defined 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. E. Mannie et. al. Internet-Draft û May 2003 2 draft-mannie-ccamp-gmpls-tdm-lbm-04.txt November 2002 LCAS (see ITU-T [G.7042]) supports 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 experience a failure in the network, and increase the capacity when the network fault is repaired. LCAS, however, does not define the mechanism whereby a VC member is provisioned or released across the network. 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 virtually concatenated signal, but can be removed from any place. The same applies in 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). 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 things the combination of the signalling provided by GMPLS and LCAS at the control and transport plane, respectively, to allow hitless modification. 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 future 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. This document extends GMPLS to allow multiple LSPs to support a single circuit and subsequently covers bandwidth modification when using multiple LSPs implementing 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. In brief, this document provides the required GMPLS signalling extensions to cover the following bandwidth modification (i.e. increase/decrease) scenarios: - GMPLS LBM without Virtual Concatenation referred to as LBM using a parallel LSP E. Mannie et. al. Internet-Draft û May 2003 3 draft-mannie-ccamp-gmpls-tdm-lbm-04.txt November 2002 - GMPLS LBM with Virtual Concatenation only . with Single LSP Bandwidth Modification . with Multiple LSP Combination (within a Circuit) - GMPLS LBM with LCAS running in sequence using GMPLS for LSP provisioning and LCAS for end-to-end in-band signalling Conventions used in this document --------------------------------- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Moreover, the reader is assumed to be familiar with the terminology in ANSI [T1.105], ITU-T [G.707] as well as [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-SONET-SDH]. The following abbreviations are used in this document: DCC: Data Communications Channel. LOVC: Lower Order Virtual Container HOVC: Higher Order Virtual Container MS: Multiplex Section. MSOH: Multiplex Section overhead. POH: Path overhead. PTE: Path Terminating Equipment. RS: Regenerator Section. RSOH: Regenerator section overhead. SDH: Synchronous digital hierarchy. SOH: Section overhead. SONET: Synchronous Optical Network. SPE: Synchronous Payload Envelope. STM(-N): Synchronous Transport Module (-N) (SDH). STS(-N): Synchronous Transport Signal-Level N (SONET). VC-n: Virtual Container-n (SDH). VTn: Virtual Tributary-n (SONET). 2. SONET/SDH Concatenation 2.1 SDH Virtual and Contiguous Concatenation Section 11 of ITU-T [G.707] 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 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 E. Mannie et. al. Internet-Draft û May 2003 4 draft-mannie-ccamp-gmpls-tdm-lbm-04.txt November 2002 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. 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 (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 = E. Mannie et. al. Internet-Draft û May 2003 5 draft-mannie-ccamp-gmpls-tdm-lbm-04.txt November 2002 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. Link Capacity Adjustment Scheme (LCAS) Link Capacity Adjustment Scheme (LCAS) recommendation ITU-T [G.7042] details the procedure to add (or remove) the payload carried by a VC-4/VC-3 within a VC-n-Xv group (n = 3, 4) and to add (or remove) the payload carried by a VC-11/VC-12/VC-2 within a VC-m-Xv group (m = 11, 12, 2). Relying on virtual concatenation support, LCAS is defined as an extended 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 requires clear determination of the interactions between these protocols. LCAS is an end-to-end (i.e. PTE-to-PTE) signalling protocol enabling bandwidth modification at end systems relying on group of virtually concatenated HOVC/STS SPE (or LOVC/VT SPE) belonging to the same circuit and provisioned through Element/Network Management Systems (EMS/NMS) or any distributed control plane. However, LCAS doesnÆt provide setting up and releasing connections between intermediate nodes. This means that LCAS must be combined with an EMS/NMS system or any distributed control plane in order for the global system to offer dynamic connection(s) setup throughout the network. The proposed GMPLS signalling extensions aim to deliver this capability including when one of the two end systems supports only virtual concatenation. E. Mannie et. al. Internet-Draft û May 2003 6 draft-mannie-ccamp-gmpls-tdm-lbm-04.txt November 2002 4. GMPLS LBM with a Parallel Connection (no Virtual Concatenation) 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 ----------- Break (GMPLS) ----------- | |VC-3 |<--------------->| VC-3| | | PTE |----- Working -----| PTE | | |VC-4 |-----------------| VC-4| | Working active ----------- ----------- With RSVP-TE, the procedures described in [RFC-3209] (Section 4.6.4) can be used but with a FF (Fixed Filter) reservation style instead of a SE (Share Explicit) style. 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. E. Mannie et. al. Internet-Draft û May 2003 7 draft-mannie-ccamp-gmpls-tdm-lbm-04.txt November 2002 Moreover, the switchover from the working connection to the new active one is strictly an end-point operation only. Also, one expects that this operation can be performed within an upper bounded period of time constraint whose definition is out of the scope of this document. When this period of time satisfies the requestor constraints, this mechanism can be considered as a non-disruptive bandwidth service modification for that application. 5. GMPLS LBM with 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. With RSVP-TE, the procedures for bandwidth modification defined in Section 4.6.4 of [RFC-3209] are used. The SENDER_TEMPLATE and the Sonet/SDH 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. 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. - 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. E. Mannie et. al. Internet-Draft û May 2003 8 draft-mannie-ccamp-gmpls-tdm-lbm-04.txt November 2002 Note also that 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 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. 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, which allows removal of any SPEs/VCs component (independently of its position within the sequence). Note: The sequence number of each SPE/VC is transported in the corresponding POH according to the SONET/SDH specifications. So, it is not necessary to transport these sequence numbers in GMPLS signaling since 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 (i.e. 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 E. Mannie et. al. Internet-Draft û May 2003 9 draft-mannie-ccamp-gmpls-tdm-lbm-04.txt November 2002 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 virtually concatenated circuit. This sequence number is a redundant information with respect to the SONET/SDH SPE/VC sequence number transported in the POH. Therefore, this allows for an additional level of consistency checking between the control plane and the transport plane. From the GMPLS signalling point of view (see also Section 5.4), these LSPs are seen as totally independent and being uniquely identified in RSVP-TE by the SESSION object together with the SENDER_TEMPLATE object (in Path message) or FILTER_SPEC object (in Resv message). 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 providing at the top of the control plane, a method for managing individual LSPs made of virtually concatenated VCs to build a larger SONET/SDH virtually concatenated circuit. This "application" SHOULD only be 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 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 when combined to the single LSP control-driven (meaning initiated by the source node and not an external event) bandwidth modification procedure defined here before, SPEs/VCs of an LSP can be removed starting from its last members (stack method). 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 parameters, except for the NVC and E. Mannie et. al. Internet-Draft û May 2003 10 draft-mannie-ccamp-gmpls-tdm-lbm-04.txt November 2002 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 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 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 Circuit ID object is defined to identify all LSPs belonging to the same SONET/SDH circuit inside of which the Sequence Number identifies each (component) LSP. This can be achieved by defining in addition to the one specified in RSVP-TE (see [RFC-3209]) a new SENDER_TEMPLATE C-Type (with Class- num = 11 and C-Type = TBA), and FILTER_SPEC C-Type (with Class-num = 10 and C-Type = TBA). Both objects have the following format: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | LSP Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 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 E. Mannie et. al. Internet-Draft û May 2003 11 draft-mannie-ccamp-gmpls-tdm-lbm-04.txt November 2002 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 MUST start at 0. Note: following the above definitions a single circuit LSP will have a Circuit ID =/= 0 and a LSP Sequence Number = 0. One expects that the Circuit ID numbering will be ordered. Processing rules: ---------------- The proposed SENDER_TEMPLATE/FILTER_SPEC object extensions are only relevant at the sender and receiver node. The corresponding objects MUST be forwarded unmodified by any intermediate node that receives them both in downstream (Path message) and upstream (Resv message) directions. If a receiver node does not support the SENDER_TEMPLATE extension described here above, a PathErr message MUST be sent back towards the sender node with Error Code 14 (Unknown object C-Type). If for the same Circuit ID a duplicated LSP Sequence Number is received, the receiver MUST send a PathErr message towards the sender with Error Code 14, and log locally the following error ôInvalid/Illegal Sequence Valueö. The sender node having inserted the SENDER_TEMPLATE by default SHOULD support the corresponding FILTER_SPEC processing, otherwise a ResvErr message MUST be sent back towards the receiver node with Error Code 14 (Unknown object C-Type). 6. GMPLS LBM with LCAS This section describes a sequential combination of GMPLS and LCAS. The proposed mechanism runs GMPLS between end-points for provisioning of a given HOVC/STS (LOVC/VT) Group (also referred to as capacity initiation, increase or decrease in ITU-T [G.7042]) and discovery of the destination support for LCAS. After this, the addition or removal of the payload carried in the HOVC/STS SPE (or LOVC/VT SPE) Group member(s) belonging to the provisioned HOVC/STS (LOVC/VT) Group is performed using LCAS end-to-end signalling. Note: that in the present application, GMPLS LBM does not replace or overlap with the end-to-end LCAS signalling and does not preclude the usage of other methods (out of the scope of the present document) for capacity initiation, increase or decrease. The detailed mechanism can be described as follows: E. Mannie et. al. Internet-Draft û May 2003 12 draft-mannie-ccamp-gmpls-tdm-lbm-04.txt November 2002 1. Bandwidth initiation, increase or decrease: 1a. Path message initiated from the Source towards the Destination that indicates the (new, in case of increase or decrease) Traffic Parameter values i.e. NVC and MT together with the capability of the Source to support LCAS; this operation is performed by using a dedicated Modifiable flag (M flag) in the ADMIN_STATUS object (see [GMPLS-RSVP]). This flag MUST follow exactly the same rules as the ones defined for any other ADMIN STATUS flag (see [GMPLS-RSVP]). 2a. Resv Message sent back by the destination towards the source (as described in Section 5.1) in addition to the indication by the receiver of LCAS support using the M flag reflection. When LCAS is supported at both ends (2) described here below applies, on the contrary, when LCAS is not supported by at least one end, (3) applies. 2. LCAS End-to-end signalling (add/remove group member) - If LCAS is supported by both ends and a bandwidth increase/ decrease is triggered at the source 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 a bandwidth increase/ decrease is triggered at the source 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 3. GMPLS LBM Signalling - If LCAS is NOT supported by at least one end, then LCAS messages are ignored by the non-supporting end which therefore only provides virtual concatenation capability. In this case the addition or removal of the HOVC/SPE (or LOVC/VT SPE) components belonging to the virtually concatenated circuit is driven by GMPLS LBM signalling as described in Section 5.1. There are no additional GMPLS signalling extensions (compared to the one proposed for virtual concatenation û see Section 5.4) required when LBM is used in combination with LCAS, except the additional M flag in the ADMIN STATUS object. Processing of this flag MUST follow the rules defined in [GMPLS-RSVP] for any other flag. 7. Security Considerations This draft introduces no new security considerations to [GMPLS- SONET-SDH]. 8. Acknowledgments E. Mannie et. al. Internet-Draft û May 2003 13 draft-mannie-ccamp-gmpls-tdm-lbm-04.txt November 2002 The authors would like to thank J. Jones, G. Grammel, A. Bellato, S. Ansorge and H. van Helvoort for their useful feedback. Valuable comments and input were also received from A. Geyssens, M. Moelants, X. Neerdaels and P. Noel and F. Yin. 9. References [GMPLS-ARCH] Mannie, E. (Editor), "GMPLS Architecture", Internet Draft, draft-ccamp-ietf-gmpls-architecture-03.txt, August 2002. [GMPLS-RSVP] Berger, L. (Editor), "Generalized MPLS Signaling - RSVP-TE Extensions", Internet Draft, draft-ietf- mpls-generalized-rsvp-te-09.txtö, October 2002. [GMPLS-SIG] Berger, L. (Editor), "Generalized MPLS û Signaling Functional Description", Internet Draft, draft-ietf- mpls-generalized-signaling-09.txt, August 2002. [GMPLS-SONET-SDH] Mannie, E. (Editor), "GMPLS Extensions for SONET and SDH Control", Internet Draft, draft-ietf-ccamp- gmpls-sonet-sdh-07.txt, October 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. [RFC3209] Awduche D., et. al., "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001. [G.707] ITU-T, ôNetwork Node Interface for the Synchronous Digital Hierarchyö, G.707 Recommendation, October 2000. [G.7042] ITU-T, ôLink Capacity Adjustment Scheme (LCAS) for Virtual Concatenated Signalsö, G.7042 Recommendation, October 2001. [T1.105] ANSI, "Synchronous Optical Network (SONET): Basic Description Including Multiplex Structure, Rates, and Formats", T1.105 Recommendation, January 2001. 10. Authors' Addresses Eric Mannie (Consulting) Email: eric_mannie@hotmail.com Dimitri Papadimitriou (Alcatel) Francis Wellesplein 1, B-2018 Antwerpen, Belgium E. Mannie et. al. Internet-Draft û May 2003 14 draft-mannie-ccamp-gmpls-tdm-lbm-04.txt November 2002 Phone: +32 3 240-8491 Email: dimitri.papadimitriou@alcatel.be Lyndon Ong (Ciena) 10480 Ridgeview Court Cupertino, CA, USA Email: lyong@ciena.com E. Mannie et. al. Internet-Draft û May 2003 15 draft-mannie-ccamp-gmpls-tdm-lbm-04.txt November 2002 11. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." E. Mannie et. al. Internet-Draft û May 2003 16