idnits 2.17.1 draft-ietf-ccamp-gmpls-sonet-sdh-08.txt: 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 Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 3 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 20 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 7713 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'G.707' == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-gmpls-architecture-03 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Eric Mannie (Consulting) - Editor 3 Internet Draft D. Papadimitriou (Alcatel) - Editor 5 Expiration Date: August 2003 February 2003 7 Generalized Multi-Protocol Label Switching Extensions for 8 SONET and SDH Control 10 draft-ietf-ccamp-gmpls-sonet-sdh-08.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are 16 working documents of the Internet Engineering Task Force (IETF), 17 its areas, and its working groups. Note that other groups may 18 also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document is a companion to the Generalized Multi-Protocol 35 Label Switching (GMPLS) signaling. It defines the Synchronous 36 Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) 37 technology specific information needed when using GMPLS signaling. 39 E.Mannie & D.Papadimitriou (Editors) 1 40 1. Introduction 42 As described in [GMPLS-ARCH], Generalized MPLS (GMPLS) extends 43 MPLS from supporting packet (Packet Switching Capable - PSC) 44 interfaces and switching to include support of four new classes of 45 interfaces and switching: Layer-2 Switch Capable (L2SC), Time- 46 Division Multiplex (TDM), Lambda Switch Capable (LSC) and Fiber- 47 Switch Capable (FSC). A functional description of the extensions 48 to MPLS signaling needed to support the new classes of interfaces 49 and switching is provided in [RFC3471]. [RFC3473] describes RSVP- 50 TE specific formats and mechanisms needed to support all five 51 classes of interfaces, and CR-LDP extensions can be found in 52 [RFC3472]. This document presents details that are specific to 53 Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy 54 (SDH). Per [RFC3471], SONET/SDH specific parameters are carried in 55 the signaling protocol in traffic parameter specific objects. 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 58 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 59 in this document are to be interpreted as described in [RFC2119]. 61 Moreover, the reader is assumed to be familiar with the terminology 62 in ANSI [T1.105], ITU-T [G.707] as well as [RFC3471], [RFC3472] and 63 [RFC3473]. The following abbreviations are used in this document: 65 DCC: Data Communications Channel. 66 LOVC: Lower Order Virtual Container 67 HOVC: Higher Order Virtual Container 68 MS: Multiplex Section. 69 MSOH: Multiplex Section overhead. 70 POH: Path overhead. 71 RS: Regenerator Section. 72 RSOH: Regenerator section overhead. 73 SDH: Synchronous digital hierarchy. 74 SOH: Section overhead. 75 SONET: Synchronous Optical Network. 76 SPE: Synchronous Payload Envelope. 77 STM(-N): Synchronous Transport Module (-N) (SDH). 78 STS(-N): Synchronous Transport Signal-Level N (SONET). 79 VC-n: Virtual Container-n (SDH). 80 VTn: Virtual Tributary-n (SONET). 82 2. SONET and SDH Traffic Parameters 84 This section defines the GMPLS traffic parameters for SONET/SDH. 85 The protocol specific formats, for the SONET/SDH-specific RSVP-TE 86 objects and CR-LDP TLVs are described in sections 2.2 and 2.3 87 respectively. 89 These traffic parameters specify indeed a base set of capabilities 90 for SONET ANSI [T1.105] and SDH ITU-T [G.707] such as 91 concatenation and transparency. Other documents may further 92 enhance this set of capabilities in the future. For instance, 94 E.Mannie & D.Papadimitriou (Editors) 2 95 signaling for SDH over PDH ITU-T G.832 or sub-STM-0 ITU-T G.708 96 interfaces could be defined. 98 The traffic parameters defined hereafter (see Section 2.1) MUST be 99 used when the label is encoded as SUKLM as defined in this memo 100 (see Section 3). They MUST also be used when requesting one of 101 Section/RS or Line/MS overhead transparent STS-1/STM-0/STS- 102 3*N/STM-N (N=1, 4, 16, 64, 256) signals. 104 The traffic parameters and label encoding defined in [RFC3471] 105 Section 3.2 MUST be used for fully transparent STS-1/STM-0/STS- 106 3*N/STM-N (N=1, 4, 16, 64, 256) signal requests. A fully 107 transparent signal is one for which all overhead is left 108 unmodified by intermediate nodes, i.e., when all defined 109 Transparency (T) bits would be set if the traffic parameters 110 defined in section 2.1 were used. 112 2.1. SONET/SDH Traffic Parameters 114 The traffic parameters for SONET/SDH are organized as follows: 116 0 1 2 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Signal Type | RCC | NCC | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | NVC | Multiplier (MT) | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Transparency (T) | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Profile (P) | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 Annex 1 lists examples of SONET and SDH signal coding. 130 Signal Type (ST): 8 bits 132 This field indicates the type of Elementary Signal that 133 comprises the requested LSP. Several transforms can be applied 134 successively on the Elementary Signal to build the Final Signal 135 being actually requested for the LSP. 137 Each transform application is optional and must be ignored if 138 zero, except the Multiplier (MT) that cannot be zero and is 139 ignored if equal to one. 141 Transforms must be applied strictly in the following order: 143 - First, contiguous concatenation (by using the RCC and NCC 144 fields) can be optionally applied on the Elementary Signal, 145 resulting in a contiguously concatenated signal. 146 - Second, virtual concatenation (by using the NVC field) can 147 be optionally applied on the Elementary Signal resulting in 148 a virtually concatenated signal. 150 E.Mannie & D.Papadimitriou (Editors) 3 151 - Third, some transparency (by using the Transparency field) 152 can be optionally specified when requesting a frame as 153 signal rather than an SPE or VC based signal. 154 - Fourth, a multiplication (by using the Multiplier field) can be 155 optionally applied either directly on the Elementary Signal, or 156 on the contiguously concatenated signal obtained from the first 157 phase, or on the virtually concatenated signal obtained from 158 the second phase, or on these signals combined with some 159 transparency. 161 Permitted Signal Type values for SONET/SDH are: 163 Value Type (Elementary Signal) 164 ----- ------------------------ 165 1 VT1.5 SPE / VC-11 166 2 VT2 SPE / VC-12 167 3 VT3 SPE 168 4 VT6 SPE / VC-2 169 5 STS-1 SPE / VC-3 170 6 STS-3c SPE / VC-4 171 7 STS-1 / STM-0 (only when requesting transparency) 172 8 STS-3 / STM-1 (only when requesting transparency) 173 9 STS-12 / STM-4 (only when requesting transparency) 174 10 STS-48 / STM-16 (only when requesting transparency) 175 11 STS-192 / STM-64 (only when requesting transparency) 176 12 STS-768 / STM-256 (only when requesting transparency) 178 A dedicated signal type is assigned to a SONET STS-3c SPE instead 179 of coding it as a contiguous concatenation of three STS-1 SPEs. 180 This is done in order to provide easy interworking between SONET 181 and SDH signaling. 183 Appendix 1 adds one signal type (optional) to the above values. 185 Requested Contiguous Concatenation (RCC): 8 bits 187 This field is used to request the optional SONET/SDH contiguous 188 concatenation of the Elementary Signal. 190 This field is a vector of flags. Each flag indicates the 191 support of a particular type of contiguous concatenation. 192 Several flags can be set at the same time to indicate a choice. 194 These flags allow an upstream node to indicate to a downstream 195 node the different types of contiguous concatenation that it 196 supports. However, the downstream node decides which one to use 197 according to its own rules. 199 A downstream node receiving simultaneously more than one flag 200 chooses a particular type of contiguous concatenation, if any 201 supported, and based on criteria that are out of this document 202 scope. A downstream node that doesn�t support any of the 203 concatenation types indicated by the field must refuse the LSP 205 E.Mannie & D.Papadimitriou (Editors) 4 206 request. In particular, it must refuse the LSP request if it 207 doesn�t support contiguous concatenation at all. 209 When several flags have been set, the upstream node retrieves 210 the (single) type of contiguous concatenation the downstream 211 node has selected by looking at the position indicated by the 212 first label and the number of label(s) as returned by the 213 downstream node (see also Section 3). 215 The entire field is set to zero to indicate that no contiguous 216 concatenation is requested at all (default value). A non-zero 217 field indicates that some contiguous concatenation is 218 requested. 220 The following flag is defined: 222 Flag 1 (bit 1): Standard contiguous concatenation. 224 Flag 1 indicates that the standard SONET/SDH contiguous 225 concatenation as defined in [T1.105]/[G.707] is supported. Note 226 that bit 1 is the low order bit. Other flags are reserved for 227 extensions, if not used they must be set to zero when sent, and 228 should be ignored when received. 230 See note 1 hereafter in the section on the NCC about the SONET 231 contiguous concatenation of STS-1 SPEs when the number of 232 components is a multiple of three. 234 Number of Contiguous Components (NCC): 16 bits 236 This field indicates the number of identical SONET SPEs/SDH VCs 237 (i.e. Elementary Signal) that are requested to be concatenated, 238 as specified in the RCC field. 240 Note 1: when requesting a SONET STS-Nc SPE with N=3*X, the 241 Elementary Signal to use must always be an STS-3c_SPE signal 242 type and the value of NCC must always be equal to X. This 243 allows also facilitating the interworking between SONET and 244 SDH. In particular, it means that the contiguous concatenation 245 of three STS-1 SPEs can not be requested because according to 246 this specification, this type of signal must be coded using the 247 STS-3c SPE signal type. 249 Note 2: when requesting a transparent STS-N/STM-N signal 250 limited to a single contiguously concatenated STS-Nc_SPE/VC-4- 251 Nc, the signal type must be STS-N/STM-N, RCC with flag 1 and 252 NCC set to 1. 254 The NCC value must be consistent with the type of contiguous 255 concatenation being requested in the RCC field. In particular, 256 this field is irrelevant if no contiguous concatenation is 257 requested (RCC = 0), in that case it must be set to zero when 258 sent, and should be ignored when received. A RCC value 260 E.Mannie & D.Papadimitriou (Editors) 5 261 different from 0 must imply a number of contiguous components 262 greater than 1. 264 Number of Virtual Components (NVC): 16 bits 266 This field indicates the number of signals that are requested 267 to be virtually concatenated. These signals are all of the same 268 type by definition. They are Elementary Signal SPEs/VCs for 269 which signal types are defined in this document, i.e. 270 VT1.5_SPE/VC-11, VT2_SPE/VC-12, VT3_SPE, VT6_SPE/VC-2, STS- 271 1_SPE/VC-3 or STS-3c_SPE/VC-4. 273 This field is set to 0 (default value) to indicate that no 274 virtual concatenation is requested. 276 Multiplier (MT): 16 bits 278 This field indicates the number of identical signals that are 279 requested for the LSP, i.e. that form the Final Signal. These 280 signals can be either identical Elementary Signals, or 281 identical contiguously concatenated signals, or identical 282 virtually concatenated signals. Note that all these signals 283 belong thus to the same LSP. 285 The distinction between the components of multiple virtually 286 concatenated signals is done via the order of the labels that 287 are specified in the signaling. The first set of labels must 288 describe the first component (set of individual signals 289 belonging to the first virtual concatenated signal), the second 290 set must describe the second component (set of individual 291 signals belonging to the second virtual concatenated signal) 292 and so on. 294 This field is set to one (default value) to indicate that exactly 295 one instance of a signal is being requested. Intermediate and 296 egress nodes MUST verify that the node itself and the interfaces 297 on which the LSP will be established can support the requested 298 multiplier value. If the requested values can not be supported, 299 the receiver node MUST generate a PathErr/NOTIFICATION message 300 (see Section 2.2/2.3, respectively). 302 Zero is an invalid value. If received, the node MUST generate a 303 PathErr/NOTIFICATION message (see Section 2.2/2.3, respectively). 305 Note 1: when requesting a transparent STS-N/STM-N signal limited 306 to a single contiguously concatenated STS-Nc-SPE/VC-4-Nc, the 307 multiplier field MUST be equal to 1 (only valid value). 309 Transparency (T): 32 bits 311 This field is a vector of flags that indicates the type of 312 transparency being requested. Several flags can be combined to 313 provide different types of transparency. Not all combinations 315 E.Mannie & D.Papadimitriou (Editors) 6 316 are necessarily valid. The default value for this field is 317 zero, i.e. no transparency requested. 319 Transparency, as defined from the point of view of this 320 signaling specification, is only applicable to the fields in 321 the SONET/SDH frame overheads. In the SONET case, these are the 322 fields in the Section Overhead (SOH), and the Line Overhead 323 (LOH). In the SDH case, these are the fields in the Regenerator 324 Section Overhead (RSOH), the Multiplex Section overhead (MSOH), 325 and the pointer fields between the two. With SONET, the pointer 326 fields are part of the LOH. 328 Note as well that transparency is only applicable when using 329 the following Signal Types: STS-1/STM-0, STS-3/STM-1, STS-12/ 330 STM-4, STS-48/STM-16, STS-192/STM-64 and STS-768/STM-256. At 331 least one transparency type must be specified when requesting 332 such a signal type. 334 Transparency indicates precisely which fields in these 335 overheads must be delivered unmodified at the other end of the 336 LSP. An ingress LSR requesting transparency will pass these 337 overhead fields that must be delivered to the egress LSR 338 without any change. From the ingress and egress LSRs point of 339 views, these fields must be seen as unmodified. 341 Transparency is not applied at the interfaces with the 342 initiating and terminating LSRs, but is only applied between 343 intermediate LSRs. 345 The transparency field is used to request an LSP that supports 346 the requested transparency type; it may also be used to setup 347 the transparency process to be applied at each intermediate 348 LSR. 350 The different transparency flags are the following: 352 Flag 1 (bit 1): Section/Regenerator Section layer. 353 Flag 2 (bit 2): Line/Multiplex Section layer. 355 Where bit 1 is the low order bit. Other flags are reserved, they 356 should be set to zero when sent, and should be ignored when 357 received. A flag is set to one to indicate that the corresponding 358 transparency is requested. 360 Intermediate and egress nodes MUST verify that the node itself and 361 the interfaces on which the LSP will be established can support 362 the requested transparency. If the requested flags can not be 363 supported, the receiver node MUST generate a PathErr/NOTIFICATION 364 message (see Section 2.2/2.3, respectively). 366 Section/Regenerator Section layer transparency means that the 367 entire frames must be delivered unmodified. This implies that 368 pointers cannot be adjusted. When using Section/Regenerator 369 Section layer transparency all other flags MUST be ignored. 371 E.Mannie & D.Papadimitriou (Editors) 7 372 Line/Multiplex Section layer transparency means that the 373 LOH/MSOH must be delivered unmodified. This implies that 374 pointers cannot be adjusted. 376 Profile (P): 32 bits 378 This field is intended to indicate particular capabilities that 379 must be supported for the LSP, for example monitoring 380 capabilities. 382 No standard profile is currently defined and this field SHOULD 383 be set to zero when transmitted and SHOULD be ignored when 384 received. 386 In the future TLV based extensions may be created. 388 2.2. RSVP-TE Details 390 For RSVP-TE, the SONET/SDH traffic parameters are carried in the 391 SONET/SDH SENDER_TSPEC and FLOWSPEC objects. The same format is 392 used both for SENDER_TSPEC object and FLOWSPEC objects. The 393 content of the objects is defined above in Section 2.1. The 394 objects have the following class and type: 396 For SONET ANSI T1.105 and SDH ITU-T G.707: 398 SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = TBA (by IANA) 399 SONET/SDH FLOWSPEC object: Class = 9, C-Type = TBA (by IANA) 401 There is no Adspec associated with the SONET/SDH SENDER_TSPEC. 402 Either the Adspec is omitted or an int-serv Adspec with the 403 Default General Characterization Parameters and Guaranteed Service 404 fragment is used, see [RFC2210]. 406 For a particular sender in a session the contents of the FLOWSPEC 407 object received in a Resv message SHOULD be identical to the 408 contents of the SENDER_TSPEC object received in the corresponding 409 Path message. If the objects do not match, a ResvErr message with 410 a "Traffic Control Error/Bad Flowspec value" error SHOULD be 411 generated. 413 Intermediate and egress nodes MUST verify that the node itself and 414 the interfaces on which the LSP will be established can support 415 the requested Signal Type, RCC, NCC, NVC and Multiplier (as 416 defined in Section 2.1). If the requested value(s) can not be 417 supported, the receiver node MUST generate a PathErr message with 418 a "Traffic Control Error/ Service unsupported" indication (see 419 [RFC2205]). 421 In addition, if the MT field is received with a zero value, the 422 node MUST generate a PathErr message with a "Traffic Control 423 Error/Bad Tspec value" indication (see [RFC2205]). 425 E.Mannie & D.Papadimitriou (Editors) 8 426 Intermediate nodes MUST also verify that the node itself and the 427 interfaces on which the LSP will be established can support the 428 requested Transparency (as defined in Section 2.1). If the 429 requested value(s) can not be supported, the receiver node MUST 430 generate a PathErr message with a "Traffic Control Error/Service 431 unsupported" indication (see [RFC2205]). 433 2.3. CR-LDP Details 435 For CR-LDP, the SONET/SDH traffic parameters are carried in the 436 SONET/SDH Traffic Parameters TLV. The content of the TLV is 437 defined above in Section 2.1. The header of the TLV has the 438 following format: 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 |U|F| Type | Length | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 The type field for the SONET/SDH Traffic Parameters TLV is: TBA 447 (by IANA). 449 Intermediate and egress nodes MUST verify that the node itself and 450 the interfaces on which the LSP will be established can support 451 the requested Signal Type, RCC, NCC, NVC and Multiplier (as 452 defined in Section 2.1). If the requested value(s) can not be 453 supported, the receiver node MUST generate a NOTIFICATION message 454 with a "Resource Unavailable" status code (see [RFC3212]). 456 In addition, if the MT field is received with a zero value, the 457 node MUST generate a NOTIFICATION message with a "Resource 458 Unavailable" status code (see [RFC3212]). 460 Intermediate nodes MUST also verify that the node itself and the 461 interfaces on which the LSP will be established can support the 462 requested Transparency (as defined in Section 2.1). If the 463 requested value(s) can not be supported, the receiver node MUST 464 generate a NOTIFICATION message with a "Resource Unavailable" 465 status code (see [RFC3212]). 467 3. SONET and SDH Labels 469 SONET and SDH each define a multiplexing structure. Both 470 structures are trees whose roots are respectively an STS-N or an 471 STM-N; and whose leaves are the signals that can be transported 472 via the time-slots and switched between time-slots within an 473 ingress port and time-slots within an egress port, i.e. a VTx SPE, 474 an STS-x SPE or a VC-x. A SONET/SDH label will identify the exact 475 position (i.e. first time-slot) of a particular VTx SPE, STS-x SPE 476 or VC-x signal in a multiplexing structure. SONET and SDH labels 477 are carried in the Generalized Label per [RFC3473] and [RFC3472]. 479 E.Mannie & D.Papadimitriou (Editors) 9 480 Note that by time-slots we mean the time-slots as they appear 481 logically and sequentially in the multiplex, not as they appear 482 after any possible interleaving. 484 These multiplexing structures will be used as naming trees to 485 create unique multiplex entry names or labels. The same format of 486 label is used for SONET and SDH. As explained in [RFC3471], a 487 label does not identify the "class" to which the label belongs. 488 This is implicitly determined by the link on which the label is 489 used. 491 In case of signal concatenation or multiplication, a list of 492 labels can appear in the Label field of a Generalized Label. 494 In case of contiguous concatenation, only one label appears in the 495 Label field. This label identifies the lowest time-slot occupied 496 by the contiguously concatenated signal. By lowest time-slot we 497 mean the one having the lowest label (value) when compared as 498 integer values, i.e. the time-slot occupied by the first component 499 signal of the concatenated signal encountered when descending the 500 tree. 502 In case of virtual concatenation, the explicit ordered list of all 503 labels in the concatenation is given. Each label indicates the 504 first time-slot occupied by a component of the virtually 505 concatenated signal. The order of the labels must reflect the 506 order of the payloads to concatenate (not the physical order of 507 time-slots). The above representation limits virtual concatenation 508 to remain within a single (component) link; it imposes as such a 509 restriction compared to the ANSI [T1.105]/ITU-T [G.707] 510 recommendations. 512 The standard definition for virtual concatenation allows each 513 virtual concatenation components to travel over diverse paths. 514 Within GMPLS, virtual concatenation components must travel over 515 the same (component) link if they are part of the same LSP. This 516 is due to the way that labels are bound to a (component) link. 517 Note however, that the routing of components on different paths is 518 indeed equivalent to establishing different LSPs, each one having 519 its own route. Several LSPs can be initiated and terminated 520 between the same nodes and their corresponding components can then 521 be associated together (i.e. virtually concatenated). 523 In case of multiplication (i.e. using the multiplier transform), 524 the explicit ordered list of all labels that take part in the 525 Final Signal is given. In case of multiplication of virtually 526 concatenated signals, the first set of labels indicates the time- 527 slots occupied by the first virtually concatenated signal, the 528 second set of labels indicates the time-slots occupied by the 529 second virtually concatenated signal, and so on. The above 530 representation limits multiplication to remain within a single 531 (component) link. 533 The format of the label for SONET and/or SDH TDM-LSR link is: 535 E.Mannie & D.Papadimitriou (Editors) 10 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | S | U | K | L | M | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 This is an extension of the numbering scheme defined in [G.707] 543 sections 7.3.7 to 7.3.13, i.e. the (K, L, M) numbering. Note that 544 the higher order numbering scheme defined in [G.707] sections 545 7.3.1 to 7.3.6 is not used here. 547 Each letter indicates a possible branch number starting at the 548 parent node in the multiplex structure. Branches are considered as 549 numbered in increasing order, starting from the top of the 550 multiplexing structure. The numbering starts at 1, zero is used to 551 indicate a non-significant or ignored field. 553 When a field is not significant or ignored in a particular context 554 it MUST be set to zero when transmitted, and MUST be ignored when 555 received. 557 When a hierarchy of SONET/SDH LSPs is used, a higher order LSP 558 with a given bandwidth can be used to carry lower order LSPs. 559 Remember here that a higher order LSP is established through a 560 SONET/SDH higher order path layer network and a lower order LSP, 561 through a SONET/SDH lower order path layer network (see also ITU-T 562 G.803, Section 3 for the corresponding definitions). In this 563 context, the higher order SONET/SDH LSP behaves as a "virtual 564 link" with a given bandwidth (e.g. VC-3), it may also be used as a 565 Forwarding Adjacency. A lower order SONET/SDH LSP can be 566 established through that higher order LSP. Since a label is local 567 to a (virtual) link, the highest part of that label (i.e. the S, U 568 and K fields) is non-significant and is set to zero, i.e. the 569 label is "0,0,0,L,M". Similarly, if the structure of the lower 570 order LSP is unknown or not relevant, the lowest part of that 571 label (i.e. the L and M fields) is non-significant and is set to 572 zero, i.e. the label is "S,U,K,0,0". 574 For instance, a VC-3 LSP can be used to carry lower order LSPs. In 575 that case the labels allocated between the two ends of the VC-3 576 LSP for the lower order LSPs will have S, U and K set to zero, 577 i.e., non-significant, while L and M will be used to indicate the 578 signal allocated in that VC-3. 580 In case of tunneling such as VC-4 containing VC-3 containing VC- 581 12/VC-11 where the SUKLM structure is not adequate to represent 582 the full signal structure, a hierarchical approach must be used, 583 i.e. per layer network signaling. 585 The possible values of S, U, K, L and M are defined as follows: 587 1. S=1->N is the index of a particular STS-3/AUG-1 inside an 588 STS-N/STM-N multiplex. S is only significant for SONET STS-N 590 E.Mannie & D.Papadimitriou (Editors) 11 591 (N>1) and SDH STM-N (N>0). S must be 0 and ignored for STS-1 and 592 STM-0. 594 2. U=1->3 is the index of a particular STS-1_SPE/VC-3 within an 595 STS-3/AUG-1. U is only significant for SONET STS-N (N>1) and SDH 596 STM-N (N>0). U must be 0 and ignored for STS-1 and STM-0. 598 3. K=1->3 is the index of a particular TUG-3 within a VC-4. K is 599 only significant for an SDH VC-4 structured in TUG-3s. K must be 600 0 and ignored in all other cases. 602 4. L=1->7 is the index of a particular VT_Group/TUG-2 within an 603 STS-1_SPE/TUG-3 or VC-3. L must be 0 and ignored in all other 604 cases. 606 5. M is the index of a particular VT1.5_SPE/VC-11, VT2_SPE/VC-12 607 or VT3_SPE within a VT_Group/TUG-2. M=1->2 indicates a specific 608 VT3 SPE inside the corresponding VT Group, these values MUST NOT 609 be used for SDH since there is no equivalent of VT3 with SDH. 610 M=3->5 indicates a specific VT2_SPE/VC-12 inside the 611 corresponding VT_Group/TUG-2. M=6->9 indicates a specific 612 VT1.5_SPE/VC-11 inside the corresponding VT_Group/TUG-2. 614 Note that a label always has to be interpreted according the 615 SONET/SDH traffic parameters, i.e. a label by itself does not 616 allow knowing which signal is being requested (a label is context 617 sensitive). 619 The label format defined in this section, referred to as SUKLM, 620 MUST be used for any SONET/SDH signal requests that are not 621 transparent i.e. when all Transparency (T) bits defined in section 622 2.1 are set to zero. Any transparent STS-1/STM-0/STS-3*N/STM-N 623 (N=1, 4, 16, 64, 256) signal request MUST use a label format as 624 defined in [RFC3471]. 626 The S encoding is summarized in the following table: 628 S SDH SONET 629 ------------------------------------------------ 630 0 other other 631 1 1st AUG-1 1st STS-3 632 2 2nd AUG-1 2nd STS-3 633 3 3rd AUG-1 3rd STS-3 634 4 4rd AUG-1 4rd STS-3 635 : : : 636 N Nth AUG-1 Nth STS-3 638 The U encoding is summarized in the following table: 640 U SDH AUG-1 SONET STS-3 641 ------------------------------------------------- 642 0 other other 643 1 1st VC-3 1st STS-1 SPE 644 2 2nd VC-3 2nd STS-1 SPE 646 E.Mannie & D.Papadimitriou (Editors) 12 647 3 3rd VC-3 3rd STS-1 SPE 649 The K encoding is summarized in the following table: 651 K SDH VC-4 652 --------------- 653 0 other 654 1 1st TUG-3 655 2 2nd TUG-3 656 3 3rd TUG-3 658 The L encoding is summarized in the following table: 660 L SDH TUG-3 SDH VC-3 SONET STS-1 SPE 661 ------------------------------------------------- 662 0 other other other 663 1 1st TUG-2 1st TUG-2 1st VTG 664 2 2nd TUG-2 2nd TUG-2 2nd VTG 665 3 3rd TUG-2 3rd TUG-2 3rd VTG 666 4 4th TUG-2 4th TUG-2 4th VTG 667 5 5th TUG-2 5th TUG-2 5th VTG 668 6 6th TUG-2 6th TUG-2 6th VTG 669 7 7th TUG-2 7th TUG-2 7th VTG 671 The M encoding is summarized in the following table: 673 M SDH TUG-2 SONET VTG 674 ------------------------------------------------- 675 0 other other 676 1 - 1st VT3 SPE 677 2 - 2nd VT3 SPE 678 3 1st VC-12 1st VT2 SPE 679 4 2nd VC-12 2nd VT2 SPE 680 5 3rd VC-12 3rd VT2 SPE 681 6 1st VC-11 1st VT1.5 SPE 682 7 2nd VC-11 2nd VT1.5 SPE 683 8 3rd VC-11 3rd VT1.5 SPE 684 9 4th VC-11 4th VT1.5 SPE 686 Examples of labels: 688 Example 1: the label for the STS-3c_SPE/VC-4 in the Sth STS-3/AUG- 689 1 is: S>0, U=0, K=0, L=0, M=0. 691 Example 2: the label for the VC-3 within the Kth-1 TUG-3 within 692 the VC-4 in the Sth AUG-1 is: S>0, U=0, K>0, L=0, M=0. 694 Example 3: the label for the Uth-1 STS-1_SPE/VC-3 within the Sth 695 STS-3/AUG-1 is: S>0, U>0, K=0, L=0, M=0. 697 Example 4: the label for the VT6/VC-2 in the Lth-1 VT Group/TUG-2 698 in the Uth-1 STS-1_SPE/VC-3 within the Sth STS-3/AUG-1 is: S>0, 699 U>0, K=0, L>0, M=0. 701 E.Mannie & D.Papadimitriou (Editors) 13 702 Example 5: the label for the 3rd VT1.5_SPE/VC-11 in the Lth-1 VT 703 Group/TUG-2 within the Uth-1 STS-1_SPE/VC-3 within the Sth STS- 704 3/AUG-1 is: S>0, U>0, K=0, L>0, M=8. 706 Example 6: the label for the STS-12c/VC-4-4c which uses the 9th 707 STS-3/AUG-1 as its first timeslot is: S=9, U=0, K=0, L=0, M=0. 709 In case of contiguous concatenation, the label that is used is the 710 lowest label (value) of the contiguously concatenated signal as 711 explained before. The higher part of the label indicates where the 712 signal starts and the lowest part is not significant. 714 In case of STM-0/STS-1, the values of S, U and K must be equal to 715 zero according to the field coding rules. For instance, when 716 requesting a VC-3 in an STM-0 the label is S=0, U=0, K=0, L=0, 717 M=0. When requesting a VC-11 in a VC-3 in an STM-0 the label is 718 S=0, U=0, K=0, L>0, M=6..9. 720 Note: when a Section/RS or Line/MS transparent STS-1/STM-0/STS- 721 3*N/STM-N (N=1, 4, 16, 64, 256) signal is requested, the SUKLM 722 label format and encoding is not applicable and the label encoding 723 MUST follow the rules defined in [RFC3471] Section 3.2. 725 4. Acknowledgments 727 Valuable comments and input were received from the CCAMP mailing 728 list where outstanding discussions took place. 730 5. Security Considerations 732 This draft introduces no new security considerations to either 733 [RFC3473] or [RFC3472]. GMPLS security is described in section 11 734 of [RFC3471] and refers to [RFC3209] for RSVP-TE and to [RFC3212] 735 for CR-LDP. 737 6. IANA Considerations 739 Three values have to be defined by IANA for this document: 741 Two RSVP C-Types in registry: 742 http://www.iana.org/assignments/rsvp-parameters 744 - A SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = TBA 745 (see section 2.2). 747 - A SONET/SDH FLOWSPEC object: Class = 9, C-Type = TBA (see 748 section 2.2). 750 One LDP TLV Type in registry: 751 http://www.iana.org/assignments/ldp-namespaces 753 - A type field for the SONET/SDH Traffic Parameters TLV 754 (see section 2.3). 756 E.Mannie & D.Papadimitriou (Editors) 14 757 7. Intellectual Property Notice 759 The IETF takes no position regarding the validity or scope of any 760 intellectual property or other rights that might be claimed to 761 pertain to the implementation or use of the technology described in 762 this document or the extent to which any license under such rights 763 might or might not be available; neither does it represent that it 764 has made any effort to identify any such rights. Information on the 765 IETF's procedures with respect to rights in standards-track and 766 standards-related documentation can be found in BCP-11. Copies of 767 claims of rights made available for publication and any assurances 768 of licenses to be made available, or the result of an attempt made 769 to obtain a general license or permission for the use of such 770 proprietary rights by implementors or users of this specification 771 can be obtained from the IETF Secretariat. 773 The IETF invites any interested party to bring to its attention any 774 copyrights, patents or patent applications, or other proprietary 775 rights which may cover technology that may be required to practice 776 this standard. Please address the information to the IETF Executive 777 Director. 779 8. References 781 8.1 Normative References 783 [G.707] ITU-T Recommendation G.707, "Network Node Interface 784 for the Synchronous Digital Hierarchy", October 2000. 786 [GMPLS-ARCH] Mannie, E., Papadimitriou D., et al., "Generalized 787 Multiprotocol Label Switching Architecture", Internet 788 Draft, Work in progress, draft-ietf-ccamp-gmpls- 789 architecture-03.txt, August 2002. 791 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 792 Requirement Levels", BCP 14, RFC 2119, March 1997. 794 [RFC2205] Braden, R., et al., "Resource ReSerVation Protocol 795 (RSVP) -- Version 1 Functional Specification", RFC 796 2205, September 1997. 798 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 799 Services," RFC 2210, September 1997. 801 [RFC3209] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for 802 LSP Tunnels", RFC 3209, December 2001. 804 [RFC3212] Jamoussi, B., et al., "Constraint-Based LSP Setup using 805 LDP", RFC 3212, January 2002. 807 [RFC3471] Berger, L. (Editor), et al., "Generalized MPLS � 808 Signaling Functional Description", RFC 3471, January 809 2003. 811 E.Mannie & D.Papadimitriou (Editors) 15 813 [RFC3472] Berger, L. (Editor), et al., "Generalized MPLS 814 Signaling - CR-LDP Extensions", RFC 3472, January 815 2003. 817 [RFC3473] Berger, L. (Editor), et al., "Generalized MPLS 818 Signaling - RSVP-TE Extensions", RFC 3473, January 819 2003. 821 [T1.105] "Synchronous Optical Network (SONET): Basic 822 Description Including Multiplex Structure, Rates, and 823 Formats", ANSI T1.105, October 2000. 825 9. Authors Addresses 827 Eric Mannie (Consulting) 828 Phone: +32 2 648-5023 829 Mobile: +32 (0)495-221775 830 Email: eric_mannie@hotmail.com 832 Dimitri Papadimitriou (Alcatel) 833 Francis Wellesplein 1, 834 B-2018 Antwerpen, Belgium 835 Phone: +32 3 240-8491 836 Email: dimitri.papadimitriou@alcatel.be 838 10. Contributors 840 Contributors are listed by alphabetical order: 842 Stefan Ansorge (Alcatel) Peter Ashwood-Smith (Nortel) 843 Lorenzstrasse 10 PO. Box 3511 Station C, 844 70435 Stuttgart, Germany Ottawa, ON K1Y 4H7, Canada 845 Email: stefan.ansorge@alcatel.de Email:petera@nortelnetworks.com 847 Ayan Banerjee (Calient) Lou Berger (Movaz) 848 5853 Rue Ferrari 7926 Jones Branch Drive 849 San Jose, CA 95138, USA McLean, VA 22102, USA 850 Email: abanerjee@calient.net Email: lberger@movaz.com 852 Greg Bernstein (Ciena) Angela Chiu (Celion) 853 10480 Ridgeview Court One Sheila Drive, Suite 2 854 Cupertino, CA 94014, USA Tinton Falls, NJ 07724-2658 855 Email: greg@ciena.com Email: angela.chiu@celion.com 857 John Drake (Calient) Yanhe Fan (Axiowave) 858 5853 Rue Ferrari 100 Nickerson Road 859 San Jose, CA 95138, USA Marlborough, MA 01752, USA 860 Email: jdrake@calient.net Email: yfan@axiowave.com 862 Michele Fontana (Alcatel) Gert Grammel (Alcatel) 863 Via Trento 30, Lorenzstrasse, 10 864 I-20059 Vimercate, Italy 70435 Stuttgart, Germany 865 Email: michele.fontana@alcatel.it Email: gert.grammel@alcatel.de 867 E.Mannie & D.Papadimitriou (Editors) 16 868 Juergen Heiles (Siemens) Suresh Katukam (Cisco) 869 Hofmannstr. 51 1450 N. McDowell Blvd, 870 D-81379 Munich, Germany Petaluma, CA 94954-6515, USA 871 Email: juergen.heiles@siemens.com Email: suresh.katukam@cisco.com 873 Kireeti Kompella (Juniper) Jonathan P. Lang (Calient) 874 1194 N. Mathilda Ave. 25 Castilian 875 Sunnyvale, CA 94089, USA Goleta, CA 93117, USA 876 Email: kireeti@juniper.net Email: jplang@calient.net 878 Fong Liaw (Solas Research) Zhi-Wei Lin (Lucent) 879 Email: fongliaw@yahoo.com 101 Crawfords Corner Rd 880 Holmdel, NJ 07733-3030, USA 881 Email: zwlin@lucent.com 883 Ben Mack-Crane (Tellabs) Dimitrios Pendarakis (Tellium) 884 Email: ben.mack-crane@tellabs.com 2 Crescent Place, P.O. Box 901 885 Oceanport, NJ 07757-0901, USA 886 Email: dpendarakis@tellium.com 888 Mike Raftelis (White Rock) Bala Rajagopalan (Tellium) 889 18111 Preston Road 2 Crescent Place, P.O. Box 901 890 Dallas, TX 75252, USA Oceanport, NJ 07757-0901, USA 891 Email: braja@tellium.com 893 Yakov Rekhter (Juniper) Debanjan Saha (Tellium) 894 1194 N. Mathilda Ave. 2 Crescent Place, P.O. Box 901 895 Sunnyvale, CA 94089, USA Oceanport, NJ 07757-0901, USA 896 Email: yakov@juniper.net Email: dsaha@tellium.com 898 Vishal Sharma (Metanoia) George Swallow (Cisco) 899 335 Elan Village Lane 250 Apollo Drive 900 San Jose, CA 95134, USA Chelmsford, MA 01824, USA 901 Email: vsharma87@yahoo.com Email: swallow@cisco.com 903 Z. Bo Tang (Tellium) Eve Varma (Lucent) 904 2 Crescent Place, P.O. Box 901 101 Crawfords Corner Rd 905 Oceanport, NJ 07757-0901, USA Holmdel, NJ 07733-3030, USA 906 Email: btang@tellium.com Email: evarma@lucent.com 908 Yangguang Xu (Lucent) 909 21-2A41, 1600 Osgood Street 910 North Andover, MA 01845, USA 911 Email: xuyg@lucent.com 913 E.Mannie & D.Papadimitriou (Editors) 17 914 11. Full Copyright Statement 916 "Copyright (C) The Internet Society (date). All Rights Reserved. 918 This document and translations of it may be copied and furnished to 919 others, and derivative works that comment on or otherwise explain it 920 or assist in its implementation may be prepared, copied, published 921 and distributed, in whole or in part, without restriction of any 922 kind, provided that the above copyright notice and this paragraph 923 are included on all such copies and derivative works. However, this 924 document itself may not be modified in any way, such as by removing 925 the copyright notice or references to the Internet Society or other 926 Internet organizations, except as needed for the purpose of 927 developing Internet standards in which case the procedures for 928 copyrights defined in the Internet Standards process must be 929 followed, or as required to translate it into languages other than 930 English. 932 The limited permissions granted above are perpetual and will not be 933 revoked by the Internet Society or its successors or assigns. 935 This document and the information contained herein is provided on an 936 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 937 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 938 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 939 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 940 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 942 E.Mannie & D.Papadimitriou (Editors) 18 943 Appendix 1 - Signal Type Values Extension for VC-3 945 This appendix defines the following optional additional Signal 946 Type value for the Signal Type field of section 2.1: 948 Value Type 949 ----- --------------------- 950 20 "VC-3 via AU-3 at the end" 952 According to the ITU-T [G.707] recommendation a VC-3 in the TU- 953 3/TUG-3/VC-4/AU-4 branch of the SDH multiplex cannot be structured 954 in TUG-2s, however a VC-3 in the AU-3 branch can be. In addition, 955 a VC-3 could be switched between the two branches if required. 957 A VC-3 circuit could be terminated on an ingress interface of an 958 LSR (e.g. forming a VC-3 forwarding adjacency). This LSR could 959 then want to demultiplex this VC-3 and switch internal low order 960 LSPs. For implementation reasons, this could be only possible if 961 the LSR receives the VC-3 in the AU-3 branch. E.g. for an LSR not 962 able to switch internally from a TU-3 branch to an AU-3 branch on 963 its incoming interface before demultiplexing and then switching 964 the content with its switch fabric. 966 In that case it is useful to indicate that the VC-3 LSP must be 967 terminated at the end in the AU-3 branch instead of the TU-3 968 branch. 970 This is achieved by using the "VC-3 via AU-3 at the end" signal 971 type. This information can be used, for instance, by the 972 penultimate LSR to switch an incoming VC-3 received in any branch 973 to the AU-3 branch on the outgoing interface to the destination 974 LSR. 976 The "VC-3 via AU-3 at the end" signal type does not imply that the 977 VC-3 must be switched via the AU-3 branch at some other places in 978 the network. The VC-3 signal type just indicates that a VC-3 in 979 any branch is suitable. 981 E.Mannie & D.Papadimitriou (Editors) 19 982 Annex 1 - Examples 984 This annex defines examples of SONET and SDH signal coding. Their 985 objective is to help the reader to understand how works the traffic 986 parameter coding and not to give examples of typical SONET or SDH 987 signals. 989 As stated above, signal types are Elementary Signals to which 990 successive concatenation, multiplication and transparency 991 transforms can be applied to obtain Final Signals. 993 1. A VC-4 signal is formed by the application of RCC with value 0, 994 NCC with value 0, NVC with value 0, MT with value 1 and T with 995 value 0 to a VC-4 Elementary Signal. 997 2. A VC-4-7v signal is formed by the application of RCC with value 998 0, NCC with value 0, NVC with value 7 (virtual concatenation of 7 999 components), MT with value 1 and T with value 0 to a VC-4 1000 Elementary Signal. 1002 3. A VC-4-16c signal is formed by the application of RCC with flag 1003 1 (standard contiguous concatenation), NCC with value 16, NVC with 1004 value 0, MT with value 1 and T with value 0 to a VC-4 Elementary 1005 Signal. 1007 4. An STM-16 signal with Multiplex Section layer transparency is 1008 formed by the application of RCC with value 0, NCC with value 0, 1009 NVC with value 0, MT with value 1 and T with flag 2 to an STM-16 1010 Elementary Signal. 1012 5. An STM-4 signal with Multiplex Section layer transparency is 1013 formed by the application of RCC with flag 0, NCC with value 0, 1014 NVC with value 0, MT with value 1 and T with flag 2 applied to an 1015 STM-4 Elementary Signal. 1017 6. An STM-256 signal with Multiplex Section layer transparency is 1018 formed by the application of RCC with flag 0, NCC with value 0, 1019 NVC with value 0, MT with value 1 and T with flag 2 applied to an 1020 STM-256 Elementary Signal. 1022 7. An STS-1 SPE signal is formed by the application of RCC with 1023 value 0, NCC with value 0, NVC with value 0, MT with value 1 and T 1024 with value 0 to an STS-1 SPE Elementary Signal. 1026 8. An STS-3c SPE signal is formed by the application of RCC with 1027 value 1 (standard contiguous concatenation), NCC with value 1, NVC 1028 with value 0, MT with value 1 and T with value 0 to an STS-3c SPE 1029 Elementary Signal. 1031 9. An STS-48c SPE signal is formed by the application of RCC with 1032 flag 1 (standard contiguous concatenation), NCC with value 16, NVC 1033 with value 0, MT with value 1 and T with value 0 to an STS-3c SPE 1034 Elementary Signal. 1036 E.Mannie & D.Papadimitriou (Editors) 20 1037 10. An STS-1-3v SPE signal is formed by the application of RCC 1038 with value 0, NVC with value 3 (virtual concatenation of 3 1039 components), MT with value 1 and T with value 0 to an STS-1 SPE 1040 Elementary Signal. 1042 11. An STS-3c-9v SPE signal is formed by the application of RCC 1043 with value 1, NCC with value 1, NVC with value 9 (virtual 1044 concatenation of 9 STS-3c), MT with value 1 and T with value 0 to 1045 an STS-3c SPE Elementary Signal. 1047 12. An STS-12 signal with Section layer (full) transparency is 1048 formed by the application of RCC with value 0, NVC with value 0, 1049 MT with value 1 and T with flag 1 to an STS-12 Elementary Signal. 1051 13. 3 x STS-768c SPE signal is formed by the application of RCC 1052 with flag 1, NCC with value 256, NVC with value 0, MT with value 1053 3, and T with value 0 to an STS-3c SPE Elementary Signal. 1055 14. 5 x VC-4-13v composed signal is formed by the application of 1056 RCC with value 0, NVC with value 13, MT with value 5 and T with 1057 value 0 to a VC-4 Elementary Signal. 1059 The encoding of these examples is summarized in the following 1060 table: 1062 Signal ST RCC NCC NVC MT T 1063 -------------------------------------------------------- 1064 VC-4 6 0 0 0 1 0 1065 VC-4-7v 6 0 0 7 1 0 1066 VC-4-16c 6 1 16 0 1 0 1067 STM-16 MS transparent 10 0 0 0 1 2 1068 STM-4 MS transparent 9 0 0 0 1 2 1069 STM-256 MS transparent 12 0 0 0 1 2 1070 STS-1 SPE 5 0 0 0 1 0 1071 STS-3c SPE 6 1 1 0 1 0 1072 STS-48c SPE 6 1 16 0 1 0 1073 STS-1-3v SPE 5 0 0 3 1 0 1074 STS-3c-9v SPE 6 1 1 9 1 0 1075 STS-12 Section transparent 9 0 0 0 1 1 1076 3 x STS-768c SPE 6 1 256 0 3 0 1077 5 x VC-4-13v 6 0 0 13 5 0 1079 E.Mannie & D.Papadimitriou (Editors) 21