idnits 2.17.1 draft-mannie-ccamp-gmpls-lbm-tdm-05.txt: -(95): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(151): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(207): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(262): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(318): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(371): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(427): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(482): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(538): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(594): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(650): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(706): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(761): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(784): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(813): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 27 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 3) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2003) is 7740 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-3471' is mentioned on line 490, but not defined == Missing Reference: 'RFC-3473' is mentioned on line 711, but not defined == Missing Reference: 'RFC-3209' is mentioned on line 583, but not defined -- Looks like a reference, but probably isn't: '0' on line 457 -- Looks like a reference, but probably isn't: '1' on line 457 -- Looks like a reference, but probably isn't: '2' on line 460 -- Looks like a reference, but probably isn't: '3' on line 460 == Unused Reference: 'GMPLS-ARCH' is defined on line 729, but no explicit reference was found in the text == Unused Reference: 'RFC2210' is defined on line 740, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 743, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 746, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 750, but no explicit reference was found in the text -- No information found for draft-ccamp-ietf-gmpls-architecture - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'GMPLS-ARCH' == Outdated reference: A later version (-08) exists of draft-ietf-ccamp-gmpls-sonet-sdh-07 -- Possible downref: Non-RFC (?) normative reference: ref. 'G.707' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.7042' Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Eric Mannie (Consult) 3 Internet Draft Dimitri Papadimitriou (Alcatel) 4 Expiration Date: August 2003 Lyndon Ong (Ciena) 6 February 2003 8 Generalized MPLS (GMPLS) LSP Bandwidth Modification (LBM) 9 for SONET/SDH Networks 11 draft-mannie-ccamp-gmpls-lbm-tdm-05.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 Abstract 31 This document defines how Generalized MPLS (GMPLS) can be used to 32 dynamically modify the bandwidth of a Time Division Multiplexing 33 (TDM) Label Switched Path (LSP). It focuses first on Synchronous 34 Optical NETwork (SONET)/Synchronous Digital Hierarchy (SDH) and 35 intends to cover other switching technologies in a further release. 37 This document also defines how to use multiple differently routed 38 LSPs to build a single SONET/SDH virtually concatenated circuit 39 where each component LSP can be subsequently recovered (i.e. 40 protected or restored) individually. 42 E. Mannie et. al. - Internet-Draft � Expires August 2003 1 43 1. Introduction 45 Generalized MPLS (GMPLS) extensions to control Synchronous Optical 46 NETwork (SONET)/Synchronous Digital Hierarchy (SDH) networks are 47 defined in [GMPLS-SONET-SDH]. They specify the SONET/SDH traffic 48 parameters to be used for SONET/SDH LSP (i.e. unidirectional or bi- 49 directional. connection) requests. 51 Dynamically changing the bandwidth allocated for a SONET/SDH 52 connection is very useful for instance, when Ethernet traffic is 53 transported over SONET/SDH connections. According to the demand, the 54 size of a concatenated SONET/SDH connection can be modified 55 dynamically without having to reestablish a new connection, and 56 potentially to interrupt the service. 58 SONET/SDH, bandwidth modification can be achieved in very different 59 ways. If not using virtual concatenation it can be realized by 60 establishing another connection between the same source and 61 destination with different characteristics (e.g. signal type) and 62 then by switching the traffic to the newly established connection by 63 performing a switchover. 65 Using virtual concatenation allows the connection bandwidth to be 66 modified by adding and removing SPEs/VCs to a connection consisting 67 of multiple SPEs/VCs. Use of LCAS further allows this to be done 68 without disruption of service. This would ideally be achieved while 69 avoiding double counting (i.e. double reservation) the resources 70 while modifying the bandwidth by using for instance the concept of 71 make-before-break. 73 In practice, bandwidth modification is most efficiently done when 74 virtual concatenation is used since SPEs/VCs don�t need to be 75 contiguous: they are transported individually and can even be routed 76 independently. This could also be achieved when using contiguous 77 concatenation but in practice this approach is much less likely to 78 happen since a bandwidth increase requires additional free SPEs/VCs 79 to be allocated at each interface traversed by the connection during 80 the switchover. 82 GMPLS signalling currently supports simultaneous setup of multiple 83 SPEs/VCs in a single setup request. This requires the SPEs/VCs 84 belonging to a single circuit to be routed through the same 85 Line/Multiplex section. This document extends the GMPLS procedures 86 to allow separate setup of multiple LSPs, possibly with disjoint 87 routing, to be coordinated at the endpoints. In that case, LSPs can 88 be set-up, maintained and deleted independently, while being part of 89 the same SONET/SDH circuit, as is desired for virtual concatenation. 90 LSPs can be co-routed through the same component TE link, through 91 different components of the same TE link or even routed completely 92 diversely, as far as T1X1/ITU-T requirements for differential delays 93 are respected (out of the scope of this document). 95 E. Mannie et. al. � Internet Draft � Expires August 2003 2 96 T1X1 and ITU-T Related Efforts: 97 ------------------------------ 99 Both have defined a protocol called Link Capacity Adjustment Scheme 100 (LCAS) for virtual concatenated (group) signals for SONET/SDH and 101 G.709 OTN (Optical Transport Networks), independently of any 102 distributed control plane. This signalling protocol transported in- 103 band in the Path Overhead (POH), for instance in SONET/SDH. 105 LCAS (see ITU-T [G.7042]) supports increasing or decreasing the 106 capacity of a virtual container that is transported using Virtual 107 Concatenation. In addition, LCAS will automatically decrease the 108 capacity if a member experience a failure in the network, and 109 increase the capacity when the network fault is repaired. LCAS, 110 however, does not define the mechanism whereby a VC member is 111 provisioned or released across the network. 113 For SDH, LCAS is defined for all VC types for which virtual 114 concatenation is defined, i.e. VC-4, VC-3, VC-2, VC-12 and VC-11. 115 Using LCAS, a VC can only be added at the end of a virtually 116 concatenated signal, but can be removed from any place. The 118 same 119 applies in SONET, where LCAS is defined for high order STS-1-Xv/STS- 120 3c-Xv and low-order VTn-Xv SPE (n = 1.5, 2, 3, 6). 122 Scope and coverage: 123 ------------------ 125 This document defines LSP Bandwidth Modification (LBM) procedures 126 and extensions for GMPLS using either virtual concatenation or 127 contiguous concatenation. It defines among other things the 128 combination of the signalling provided by GMPLS and LCAS at the 129 control and transport plane, respectively, to allow hitless 130 modification. Note the current version focuses on SONET/SDH and will 131 in a future release cover G.709 Optical Transport Networks (OTN). 133 Similarly to GMPLS, this document covers bandwidth modification of 134 unidirectional LSPs and bi-directional symmetric LSPs. Bi- 135 directional asymmetric LSPs setup is not supported by the current 136 GMPLS Signalling specification. In this context, the current 137 proposal allows for SONET/SDH bandwidth modification being requested 138 only by the initiator (source) of a circuit. A future version might 139 cover destination initiated bandwidth modification. It could also be 140 extended to cover modification of other connection attributes than 141 the bandwidth, like link protection/restoration characteristics. 143 This document extends GMPLS to allow multiple LSPs to support a 144 single circuit and subsequently covers bandwidth modification when 145 using multiple LSPs implementing a single circuit. This approach has 146 the drawback of requiring more signalling but seems to be more 147 appropriated when operating within the context of a global control 148 plane. It provides the advantage that each LSP can be routed 149 independently AND protected/restored independently. Note that GMPLS 151 E. Mannie et. al. � Internet Draft � Expires August 2003 3 152 LBM can be first used to modify the bandwidth of a single unique LSP 153 (circuit), without any LSP combination. 155 In brief, this document provides the required GMPLS signalling 156 extensions to cover the following bandwidth modification (i.e. 157 increase/decrease) scenarios: 159 - GMPLS LBM without Virtual Concatenation referred to as LBM using 160 a parallel LSP 162 - GMPLS LBM with Virtual Concatenation only 163 . with Single LSP Bandwidth Modification 164 . with Multiple LSP Combination (within a Circuit) 166 - GMPLS LBM with both Virtual Concatenation and LCAS using GMPLS for 167 LSP provisioning and LCAS for end-to-end (in-band) signalling 169 Conventions used in this document 170 --------------------------------- 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 173 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 174 in this document are to be interpreted as described in [RFC2119]. 176 Moreover, the reader is assumed to be familiar with the terminology 177 in ANSI [T1.105], ITU-T [G.707] as well as [RFC-3471], [RFC-3473] 178 and [GMPLS-SONET-SDH]. The following abbreviations are used in this 179 document: 181 DCC: Data Communications Channel. 182 LOVC: Lower Order Virtual Container. 183 HOVC: Higher Order Virtual Container. 184 MS: Multiplex Section. 185 MSOH: Multiplex Section overhead. 186 POH: Path overhead. 187 PTE: Path Terminating Equipment. 188 RS: Regenerator Section. 189 RSOH: Regenerator section overhead. 190 SDH: Synchronous digital hierarchy. 191 SOH: Section overhead. 192 SONET: Synchronous Optical Network. 193 SPE: Synchronous Payload Envelope. 194 STM(-N): Synchronous Transport Module (-N) (SDH). 195 STS(-N): Synchronous Transport Signal-Level N (SONET). 196 VC-n: Virtual Container-n (SDH). 197 VTn: Virtual Tributary-n (SONET). 199 2. SONET/SDH Concatenation 201 2.1 SDH Virtual and Contiguous Concatenation 203 Section 11 of ITU-T [G.707] recommendation defines VC contiguous and 204 virtual concatenation. Contiguous concatenation maintains the 205 bandwidth contiguous through the whole network, while virtual 207 E. Mannie et. al. � Internet Draft � Expires August 2003 4 208 concatenation breaks the bandwidth into individuals VCs, transports 209 and routes these VCs individually from the source and then 210 recombines them at the path termination. Virtual concatenation 211 requires concatenation functionality only at the path termination 212 equipment, while contiguous concatenation requires concatenation 213 functionality at each network element: 215 - Contiguous concatenation is defined for VC-4s to provide a VC-4-Xc 216 (X=4, 16, 64, 256) and for VC-2s in a higher order VC-3 to provide 217 a VC-2-Xc (X=1,...,7). 219 - Virtual concatenation is defined for VC-4s, VC-3s, VC-2s, VC-12s 220 and VC-11s but all the VCs belonging to a virtually concatenated 221 circuit must be of the same type. The virtual concatenation of X 222 VC-4/3 (X=1,...,256) provides a VC-4/3-Xv. The number of low order 223 VCs that can be virtually concatenated together depends on the 224 higher order VC in which they are transported and is defined 225 according to table 11-9 in G.707. 227 Each VC has its own Path Overhead (POH): 229 - For low order VC: the VC-2/1 K4 POH byte in bit 2 is multi-framed 230 in 32 frames to form a 32 bits string and is used to indicate a 231 frame count and a sequence indicator. The frame count provides a 232 measure of the differential delay (see ITU-T G.707). Each VC-2/1 233 of a VC-2/1-Xv has a fixed unique sequence number in the range of 234 0 to X-1. 236 - For high order VC: the VC-4/3 H4 POH byte is used for the virtual 237 concatenation specific sequence and multi-frame indication. What 238 is important in the context of GMPLS LBM is that each VC-4/3 has a 239 fixed sequence number in the range of 0 to X-1. 241 These VC sequence numbers will be used by the GMPLS LBM procedures 242 to identify each frame unambiguously in the same virtually 243 concatenated circuit. 245 VCs can be routed and transported individually, even over different 246 multiplex sections, i.e. over different TE link components or over 247 different TE links. There are limitations due to the differential 248 delay between different routes (outside of the scope of this 249 document). GMPLS LBM provides the same level of flexibility, using 250 and combining multiple LSPs. 252 2.2 SONET Virtual and Contiguous Concatenation 254 ANSI [T1.105] recommendation defines VC contiguous and virtual 255 concatenation. Contiguous concatenation maintains the bandwidth 256 contiguous through the whole network, while virtual concatenation 257 breaks the bandwidth into individuals STS SPEs, transports and 258 routes these STS SPEs individually from the source and then 259 recombines them at the path termination. Virtual concatenation 260 requires concatenation functionality only at the path termination 262 E. Mannie et. al. � Internet Draft � Expires August 2003 5 263 equipment, while contiguous concatenation requires concatenation 264 functionality at each network element: 266 - Contiguous concatenation is defined for STS-1/STS-3c SPEs to 267 provide a STS-(3*X)c SPE (X=1, 4, 16, 64, 256) 268 - Virtual concatenation is defined for STS-1s, STS-3cs and VTn SPEs 269 (n = 1.5, 2, 3, 6) but all the STS/VT SPEs belonging to a 270 virtually concatenated circuit must be of the same type. The 271 virtual concatenation of X STS-1/STS-3c (X=1,...,256) provides 272 a STS-1-Xv/STS-3c-Xv SPE. The number of low order VTn SPEs (n = 273 1.5, 2, 3, 6) that can be virtually concatenated together depends 274 on the higher order STS-1/STS-3c SPE in which they are transported 275 as defined according to Table 8 of ANSI T1.105. 277 Each VT/STS SPE has its own Path Overhead (POH): 278 - For low order VT SPEs: the VTn Z7 POH byte in bit 2 is multi- 279 framed in 32 frames to form a 32 bits string and is used to 280 indicate a frame count and a sequence indicator. The frame count 281 provides a measure of the differential delay (see ANSI [T1.105]). 282 Each VTn SPE of a VTn-Xv SPE has a fixed unique sequence number in 283 the range of 0 to X-1. 284 - For high order STS SPEs: the STS-1/STS-3c H4 POH byte is used for 285 the virtual concatenation specific sequence and multi-frame 286 indication. It uses a two-stage multi-framing. As for SDH, the 287 important point in the context of GMPLS LBM is that each STS- 288 1/STS-3c SPE has a fixed sequence number in the range of 0 to X-1. 290 These sequence numbers will be used by the GMPLS LBM procedures to 291 identify each frame unambiguously in the same virtually concatenated 292 circuit. As for SDH, VTs/STS SPEs can be routed and transported 293 individually, even over different line sections, i.e. over different 294 TE link components or over different TE links. 296 3. Link Capacity Adjustment Scheme (LCAS) 298 Link Capacity Adjustment Scheme (LCAS) recommendation ITU-T [G.7042] 299 details the procedure to add (or remove) the payload carried by a 300 VC-4/VC-3 within a VC-n-Xv group (n = 3, 4) and to add (or remove) 301 the payload carried by a VC-11/VC-12/VC-2 within a VC-m-Xv group (m 302 = 11, 12, 2). Relying on virtual concatenation support, LCAS is 303 defined as an extended end-to-end signalling protocol transported 304 over the H4 overhead (for HOVC) and K4 overhead (for LOVC). The same 305 applies in SONET for high order STS-1-Xv/STS-3c-Xv and low-order 306 VTn-Xv SPE (n = 1.5, 2, 3, 6) signalling being transported over H4 307 and Z7 POH, respectively. 309 Running GMPLS at the control plane level and LCAS at the transport 310 plane level requires clear determination of the interactions between 311 these protocols. LCAS is an end-to-end (i.e. PTE-to-PTE) signalling 312 protocol enabling bandwidth modification at end systems relying on 313 group of virtually concatenated HOVC/STS SPE (or LOVC/VT SPE) 314 belonging to the same circuit and provisioned through 315 Element/Network Management Systems (EMS/NMS) or any distributed 316 control plane. However, LCAS doesn�t provide setting up and 318 E. Mannie et. al. � Internet Draft � Expires August 2003 6 319 releasing connections between intermediate nodes. This means that 320 LCAS must be combined with an EMS/NMS system or any distributed 321 control plane in order for the global system to offer dynamic 322 connection(s) setup throughout the network. The proposed GMPLS 323 signalling extensions aim to deliver this capability including when 324 one of the two end systems supports only virtual concatenation. 326 4. GMPLS LBM with a Parallel Connection (no Virtual Concatenation) 328 This section describes how to modify the bandwidth of a connection 329 by establishing a new completely bandwidth disjoint connection and 330 moving the traffic to the newly established connection by doing a 331 switchover at the end-points. This procedure can be performed 332 manually or automatically. It also uses a simplified version of the 333 make-before-break concept. 335 A new disjoint connection is first established. It can be routed 336 differently from the original connection and may have completely 337 different traffic parameters. This new connection reserves its own 338 resources and before performing the switchover, some bandwidth may 339 be double reserved. 341 This is for instance the only way to change the bandwidth of an 342 SDH LSP from a non-concatenated VC type to a different non- 343 concatenated VC type. An example is when going from a VC-3 to a VC-4 344 for an IP/MPLS bandwidth upgrade. This situation is depicted in the 345 following figure: 347 Step 1: Make 349 ----------- Working ----------- 350 | |VC-3 |-----------------| VC-3| | Working active 351 | PTE |----- Make (GMPLS) -----| PTE | 352 | |VC-4 |<--------------->| VC-4| | 353 ----------- ----------- 355 Step 2: Share 357 ----------- Working ----------- 358 | |VC-3 |<--------------->| VC-3| | Working active 359 | PTE |----- Working -----| PTE | 360 | |VC-4 |<--------------->| VC-4| | Working standby 361 ----------- ----------- 363 Step 3: Break 365 ----------- Break (GMPLS) ----------- 366 | |VC-3 |<--------------->| VC-3| | 367 | PTE |----- Working -----| PTE | 368 | |VC-4 |-----------------| VC-4| | Working active 369 ----------- ----------- 371 E. Mannie et. al. � Internet Draft � Expires August 2003 7 372 With RSVP-TE, the procedures described in [RFC-3209] (Section 4.6.4) 373 can be used but with a FF (Fixed Filter) reservation style instead 374 of a SE (Share Explicit) style. 376 The major point is that the LSP destination must be able to 377 understand that 1) a new LSP is intended to replace an existing LSP 378 and 2) this newly setup LSP is not independent of the existing one. 379 This is achieved using the mechanism explained here above. 381 Moreover, the switchover from the working connection to the new 382 active one is strictly an end-point operation only. Also, one 383 expects that this operation can be performed within an upper bounded 384 period of time constraint whose definition is out of the scope of 385 this document. When this period of time satisfies the requestor 386 constraints, this mechanism can be considered as a non-disruptive 387 bandwidth service modification for that application. 389 5. GMPLS LBM with Virtual Concatenation 391 This section defines the procedures for SONET/SDH bandwidth 392 modification when virtual concatenation is used. It first defines 393 the procedures to add or remove VCs in a single LSP (Section 5.1), 394 and then the one enabling to combine several LSPs together (Section 395 5.2). 397 5.1 Single LSP Bandwidth Modification 399 This section is only applicable to the standard virtual 400 concatenation as defined by T1X1/ITU-T (see [T1.105] and [G.707], 401 respectively). 403 SONET/SDH LSP bandwidth modification can only be allowed when the 404 LSP is already set up and active, i.e. modification is not defined 405 or allowed during the LSP(s) establishment or release. Only 406 bandwidth modification requested by the ingress LSR of the LSP is 407 considered here. The Ingress LSR shall not modify an LSP before a 408 previous modification procedure is completed. 410 When a bandwidth modification is requested, an updated SONET/SDH 411 traffic parameter is sent downstream within a Path/Label 412 Request message. This request is explicitly identified as a 413 bandwidth modification request using a specific indication 414 mechanism. 416 With RSVP-TE, the procedures for bandwidth modification defined in 417 Section 4.6.4 of [RFC-3209] are used. The SENDER_TEMPLATE and the 418 Sonet/SDH SENDER_TSPEC objects carry respectively a modified LSP ID 419 and a modified SONET/SDH traffic parameter within the Path message 420 sent from the source LSR (i.e. head-end PTE) to the destination LSR 421 (i.e. tail-end PTE). This allows recognizing that a bandwidth 422 modification is requested. 424 Subsequently, the following alternative can be considered: 425 - If accepted, the same new traffic parameter is sent back to the 427 E. Mannie et. al. � Internet Draft � Expires August 2003 8 428 source indicating a bandwidth modification of a unidirectional or 429 a bi-directional LSP. This traffic parameter is transported in the 430 FLOWSPEC of the Resv message with RSVP-TE. 431 - If refused, the previously used SONET/SDH traffic parameter is 432 sent back to the source. It allows ensuring that the request for 433 bandwidth modification was well received and treated by the 434 destination without commitment of the requested modification. 436 Note also that the actual bandwidth allocation is committed when the 437 Resv message flows in the upstream direction. 439 A modified SONET/SDH traffic parameter SHOULD have a different NVC 440 field and MAY have a different MT field. The Multiplier field (MT) 441 SHOULD not be used since this field has a different semantic. All 442 other fields MUST be identical. 444 SPEs/VCs can only be added at the end of an LSP. For instance, when 445 adding Y VC-4s to a VC-4-Xv (where each of the VC-4 is numbered from 446 0 to X-1), one obtains a VC-4-(X+Y)v with the sequence numbered from 447 0 to X+Y-1. 449 The number Y of SPEs/VCs to add is given by the following equation: 450 ABS[(new NVC * new MT) - (old NVC * old MT)]. The first new SPE/VC 451 will have a sequence number equals to the sequence number of the 452 previously last VC + 1 (i.e. X). 454 Example: 456 Old Traffic Parameters: ST = VC-4 - NVC = 2 - MT = 1 (VC-4-2v) 457 Sequence: VC-4[0] = 0 and VC-4[1] = 1 459 New Traffic Parameters: ST = VC-4 - NVC = 4 - MT = 1 (ADD 2 VC-4) 460 Sequence: VC-4[2] = 2 and VC-4[3] = 3 462 GMPLS LBM explicitly allows the value of the traffic parameters to 463 change over time. Modified SONET/SDH traffic parameter indicates the 464 complete traffic parameters of the updated circuit and not a delta. 465 The delta computation is simply done by comparing the fields. 467 SPEs/VCs can be removed from an LSP but only at the end of that LSP 468 (i.e. starting at SPE/VC sequence number X-1). When a new traffic 469 parameter is sent requesting less SPEs/VCs, the difference is 470 removed from the end of the sequence. This is a limitation in 471 comparison with LCAS, which allows removal of any SPEs/VCs component 472 (independently of its position within the sequence). 474 Note: The sequence number of each SPE/VC is transported in the 475 corresponding POH according to the SONET/SDH specifications. So, it 476 is not necessary to transport these sequence numbers in GMPLS 477 signaling since they are implicitly deduced at each end according to 478 the order of operations. When adding or removing SPEs/VCs, the 479 sequence numbers of the other (i.e. previous) SPEs/VCs of the same 480 LSP are not modified and stay identical. 482 E. Mannie et. al. � Internet Draft � Expires August 2003 9 483 5.2 Multiple LSPs Combination 485 The reasons to combine multiple LSPs to provide one larger SONET/SDH 486 circuit were already explained before. Such a combination requires 487 that all LSPs belonging to the same circuit be clearly identified as 488 belonging to the same group and as being in a given order. Defining 489 an additional Circuit ID and an LSP Sequence Number in GMPLS 490 signalling [RFC-3471] enables to achieve this. Obviously, each LSP 491 of the combination may have a different number of SPEs/VCs. 493 The following rules are defined together with the introduction of 494 the Circuit ID and the LSP Sequence Number: 495 - All LSPs belonging to the same circuit MUST have the same Circuit 496 ID 497 - All LSPs MUST have a unique LSP sequence number in that Circuit ID 499 The LSP sequence number MUST be the sequence number of the first 500 SPE/VC of the virtually concatenated circuit. This sequence number 501 is a redundant information with respect to the SONET/SDH SPE/VC 502 sequence number transported in the POH. Therefore, this allows for 503 an additional level of consistency checking between the control 504 plane and the transport plane. 506 From the GMPLS signalling point of view (see also Section 5.4), 507 these LSPs are seen as totally independent and being uniquely 508 identified in RSVP-TE by the SESSION object together with the 509 SENDER_TEMPLATE object (in Path message) or FILTER_SPEC object (in 510 Resv message). They can be co-routed or not. They can be routed 511 explicitly diversely or not. They can fail separately and be 512 individually protected/restored or not. 514 Therefore, in this context, the GMPLS LBM "application" can be 515 considered as providing at the top of the control plane, a method 516 for managing individual LSPs made of virtually concatenated VCs to 517 build a larger SONET/SDH virtually concatenated circuit. This 518 "application" SHOULD only be supported at each end of an SONET/SDH 519 circuit without impacting intermediate nodes. 521 All SPEs/VCs corresponding to a new LSP can only be added at the end 522 of the virtually concatenated signal sequence. In that case, the 523 SPE/VC sequence number of the first SPE/VC is the sequence number of 524 the last SPE/VC of the last LSP + 1. 526 When an LSP is removed, for whatever reason, all its SPEs/VCs are 527 removed. This implies that sequence numbers of other SPEs/VCs 528 belonging to the LSPs logically following the removed LSP MUST be 529 renumbered. The same is done for the LSP sequence numbers. However, 530 this is not an issue since all the LSPs are initiated by the same 531 entity. 533 Note that when combined to the single LSP control-driven (meaning 534 initiated by the source node and not an external event) bandwidth 535 modification procedure defined here before, SPEs/VCs of an LSP can 536 be removed starting from its last members (stack method). It results 538 E. Mannie et. al. � Internet Draft � Expires August 2003 10 539 in a multi-LSP configuration that SPEs/VCs can also be removed 540 independently of a complete LSP removal but with the given 541 restriction. 543 All LSPs belonging to the same virtually concatenated signal MUST 544 have the same SONET/SDH traffic parameters, except for the NVC and 545 MT fields. Note however that the use of the multiplier (MT) in that 546 context is not at all recommended. 548 5.3 SPE/VC recognition and significance 550 When a modification occurs in a virtually concatenated signal, the 551 receiving end needs to know which SPE/VC is part of the circuit and 552 when the content of each SPE/VC is valid. 554 A SPE/VC is considered as being part of circuit when it is signaled, 555 i.e. when the corresponding Resv message is sent back to the source. 556 The SPE/VC content is considered as significant when it is received 557 with a specific indication in the POH (it can also be located for 558 HOVC/STS SPE in the H4 POH byte as defined by LCAS) and a valid 559 sequence number according to the receiving end status. 561 The sequence number transported in the POH has a global significance 562 per circuit not per LSP. Since multi-frames are used, the sequence 563 number is considered usable only when the last bit of the multi- 564 framed field has been received. 566 Note: to ensure that in the upstream direction the destination end 567 doesn�t send traffic before the source completed the bandwidth 568 modification; the destination end MAY simply wait for a ResvConf to 569 be received. 571 5.4 GMPLS Signalling Extensions 573 This memo requires the encoding and transport of a Circuit ID and an 574 LSP Sequence Number for all LSPs being established according to the 575 procedures of Section 5.2. Having a Circuit ID even for a single LSP 576 circuit further allows adding LSPs to this circuit. 578 A Circuit ID object is defined to identify all LSPs belonging to the 579 same SONET/SDH circuit inside of which the Sequence Number 580 identifies each (component) LSP. 582 This can be achieved by defining in addition to the one specified in 583 RSVP-TE (see [RFC-3209]) an extended SENDER_TEMPLATE C-Type (with 584 Class-num = 11 and C-Type = TBA), and extended FILTER_SPEC C-Type 585 (with Class-num = 10 and C-Type = TBA). Both objects have the 586 following format: 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Circuit ID | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 E. Mannie et. al. � Internet Draft � Expires August 2003 11 595 | MUST be zero | LSP Sequence Number | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 - Circuit ID field (32 bits) 600 This is a unique Circuit ID number, generated by the source. It 601 is unique in the context of the source and does not change during 602 the lifetime of the circuit. 604 In the current version, when used this field MUST be non-zero. 606 - LSP Sequence Number field (16 bits) 608 This is a unique sequence number in the context of the Circuit 609 ID. It allows ordering the LSP in the SONET/SDH virtually 610 concatenated signal. Numbering MUST start at 0. This field is 611 relevant only when fixed timeslot allocation is provided at 612 virtual concatenation end-points. 614 Note: following the above definitions a single circuit LSP will have 615 a Circuit ID =/= 0 and a LSP Sequence Number = 0. One expects that 616 the Circuit ID numbering will be ordered. 618 Processing rules: 619 ---------------- 621 The proposed SENDER_TEMPLATE/FILTER_SPEC object extensions are only 622 relevant at the sender and receiver nodes. The corresponding objects 623 MUST be forwarded unmodified by any intermediate node that receives 624 them in both downstream (Path message) and upstream (Resv message) 625 directions. Maintenance of this object in the local PSB is optional, 626 thus the current path records can be left unmodified (compose by the 627 EXPLICIT ROUTE object, SESSION object and SENDER_TEMPLATE object) 628 from its current implementation. 630 If a receiver node does not support the SENDER_TEMPLATE extension 631 described here above, a PathErr message MUST be sent back towards 632 the sender node with Error Code 14 (Unknown object C-Type). If for 633 the same Circuit ID a duplicated LSP Sequence Number is received, 634 the receiver MUST send a PathErr message towards the sender with 635 Error Code 14, and log locally the following error �Invalid/Illegal 636 Sequence Value�. 638 The sender node having inserted the SENDER_TEMPLATE by default 639 SHOULD support the corresponding FILTER_SPEC processing, otherwise a 640 ResvErr message MUST be sent back towards the receiver node with 641 Error Code 14 (Unknown object C-Type). 643 6. GMPLS LBM with both Virtual Concatenation and LCAS 645 This section describes a sequential combination of GMPLS and LCAS. 646 The proposed mechanism runs GMPLS between virtual concatenation 647 capable end-points for provisioning of a given HOVC/STS (LOVC/VT) 648 Group (also referred to as capacity initiation, increase or decrease 650 E. Mannie et. al. � Internet Draft � Expires August 2003 12 651 in ITU-T [G.7042]) and discovery of the destination support for 652 LCAS. After this, the addition or removal of the payload carried in 653 the HOVC/STS SPE (or LOVC/VT SPE) Group member(s) belonging to the 654 provisioned HOVC/STS (LOVC/VT) Group is performed using LCAS end-to- 655 end signalling. 657 Note: that in the present application, GMPLS LBM does not replace or 658 overlap with the end-to-end LCAS signalling and does not preclude 659 the usage of other methods (out of the scope of the present 660 document) for capacity initiation, increase or decrease. 662 The detailed mechanism can be described as follows: 664 1. Bandwidth initiation, increase or decrease: 666 1a. Path message initiated from the Source towards the 667 Destination that indicates the (new, in case of increase or 668 decrease) Traffic Parameter values i.e. NVC and MT together 669 with the capability of the Source to support LCAS; this 670 operation is performed by using a dedicated Modifiable flag 671 (M flag) in the ADMIN_STATUS object (see [RFC-3473]). This 672 flag MUST follow exactly the same rules as the ones defined 673 for any other ADMIN STATUS flag (see [RFC-3473]). 675 2a. Resv Message sent back by the destination towards the source 676 (as described in Section 5.1) in addition to the indication 677 by the receiver of LCAS support using the M flag reflection. 679 When LCAS is supported at both ends (2) described here below 680 applies, on the contrary, when LCAS is not supported by at least 681 one end, (3) applies. 683 2. LCAS End-to-end signalling (add/remove group member) 685 - If LCAS is supported by both ends and a bandwidth increase/ 686 decrease is triggered at the source for a unidirectional LSP: 687 3a. LCAS end-to-end signalling protocol used to exchange the H4 688 CTRL messages 689 4a. Trigger the H4 NORM value and use the allocated bandwidth 691 - If LCAS is supported by both ends and a bandwidth increase/ 692 decrease is triggered at the source for a bi-directional LSP: 693 3b. LCAS end-to-end signalling protocol used to exchange the H4 694 CTRL messages 695 4b. Trigger the H4 NORM value and use the allocated bandwidth 697 3. GMPLS LBM Signalling 699 - If LCAS is NOT supported by at least one end, then LCAS 700 messages are ignored by the non-supporting end which therefore 701 only provides virtual concatenation capability. In this case 702 the addition or removal of the HOVC/SPE (or LOVC/VT SPE) 703 components belonging to the virtually concatenated circuit is 704 driven by GMPLS LBM signalling as described in Section 5.1. 706 E. Mannie et. al. � Internet Draft � Expires August 2003 13 707 There are no additional GMPLS signalling extensions (compared to the 708 one proposed for virtual concatenation � see Section 5.4) required 709 when LBM is used in combination with LCAS, except the additional M 710 flag in the ADMIN STATUS object. Processing of this flag MUST follow 711 the rules defined in [RFC-3473] for any other flag. 713 7. Security Considerations 715 This draft introduces no new security considerations to [GMPLS- 716 SONET-SDH]. 718 8. Acknowledgments 720 The authors would like to thank J. Jones, G. Grammel, A. Bellato, 721 S. Ansorge, S.De Cnodder and H. van Helvoort for their useful 722 feedback. 724 Valuable comments and input were also received from A. Geyssens, 725 M. Moelants, X. Neerdaels and P. Noel and F. Yin. 727 9. References 729 [GMPLS-ARCH] Mannie, E. (Editor), "GMPLS Architecture", Internet 730 Draft, draft-ccamp-ietf-gmpls-architecture-03.txt, 731 August 2002. 733 [GMPLS-SONET-SDH] Mannie, E. (Editor), "GMPLS Extensions for SONET 734 and SDH Control", Internet Draft, draft-ietf-ccamp- 735 gmpls-sonet-sdh-07.txt, October 2002. 737 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 738 Requirement Levels," RFC 2119. 740 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 741 Services," RFC 2210, September 1997. 743 [RFC3209] Awduche D., et al., "RSVP-TE: Extensions to RSVP for 744 LSP Tunnels," RFC 3209, December 2001. 746 [RFC3471] Berger, L. (Editor) et al., "Generalized MPLS � 747 Signaling Functional Description", RFC 3471, January 748 2003. 750 [RFC3473] Berger, L. (Editor) et al., "Generalized MPLS 751 Signaling - RSVP-TE Extensions", RFC 3473, January 752 2003. 754 [G.707] ITU-T, �Network Node Interface for the Synchronous 755 Digital Hierarchy�, G.707 Recommendation, October 756 2000. 758 [G.7042] ITU-T, �Link Capacity Adjustment Scheme (LCAS) for 759 Virtual Concatenated Signals�, G.7042 Recommendation, 761 E. Mannie et. al. � Internet Draft � Expires August 2003 14 762 October 2001. 764 [T1.105] ANSI, "Synchronous Optical Network (SONET): Basic 765 Description Including Multiplex Structure, Rates, and 766 Formats", T1.105 Recommendation, January 2001. 768 10. Authors' Addresses 770 Eric Mannie (Consult) 771 Email: eric_mannie@hotmail.com 773 Dimitri Papadimitriou (Alcatel) 774 Francis Wellesplein 1, 775 B-2018 Antwerpen, Belgium 776 Phone: +32 3 240-8491 777 Email: dimitri.papadimitriou@alcatel.be 779 Lyndon Ong (Ciena) 780 5965 Silver Creek Valley Road 781 San Jose, CA 95138, USA 782 Email: lyong@ciena.com 784 E. Mannie et. al. � Internet Draft � Expires August 2003 15 785 11. Full Copyright Statement 787 "Copyright (C) The Internet Society (date). All Rights Reserved. 789 This document and translations of it may be copied and furnished to 790 others, and derivative works that comment on or otherwise explain it 791 or assist in its implementation may be prepared, copied, published 792 and distributed, in whole or in part, without restriction of any 793 kind, provided that the above copyright notice and this paragraph 794 are included on all such copies and derivative works. However, this 795 document itself may not be modified in any way, such as by removing 796 the copyright notice or references to the Internet Society or other 797 Internet organizations, except as needed for the purpose of 798 developing Internet standards in which case the procedures for 799 copyrights defined in the Internet Standards process must be 800 followed, or as required to translate it into languages other than 801 English. 803 The limited permissions granted above are perpetual and will not be 804 revoked by the Internet Society or its successors or assigns. 806 This document and the information contained herein is provided on an 807 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 808 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 809 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 810 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 811 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 813 E. Mannie et. al. � Internet Draft � Expires August 2003 16