idnits 2.17.1 draft-ietf-ccamp-gmpls-sonet-sdh-06.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 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 21 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (August 2002) is 7924 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 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-06 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-07 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-08 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Eric Mannie (KPNQwest) - Editor 3 Internet Draft Dimitri Papadimitriou (Alcatel) - Editor 5 Expiration Date: February 2003 August 2002 7 Generalized Multiprotocol Label Switching Extensions for 8 SONET and SDH Control 10 draft-ietf-ccamp-gmpls-sonet-sdh-06.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 Multiprotocol 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 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 42 Contributors 44 Contributors are listed by alphabetical order. 46 Stefan Ansorge (Alcatel) 47 Lorenzstrasse 10 48 70435 Stuttgart, Germany 49 Phone: +49 711 821-33744 50 Email: stefan.ansorge@alcatel.de 52 Peter Ashwood-Smith (Nortel Networks Corp.) 53 P.O. Box 3511 Station C, 54 Ottawa, ON K1Y 4H7, Canada 55 Phone: +1 613 763-4534 56 Email: petera@nortelnetworks.com 58 Ayan Banerjee (Calient Networks) 59 5853 Rue Ferrari 60 San Jose, CA 95138, USA 61 Phone: +1 408 972-3645 62 Email: abanerjee@calient.net 64 Lou Berger (Movaz Networks, Inc.) 65 7926 Jones Branch Drive 66 Suite 615 67 McLean VA, 22102, USA 68 Phone: +1 703 847-1801 69 Email: lberger@movaz.com 71 Greg Bernstein (Ciena Corporation) 72 10480 Ridgeview Court 73 Cupertino, CA 94014, USA 74 Phone: +1 408 366-4713 75 Email: greg@ciena.com 77 Angela Chiu (Celion Networks) 78 One Sheila Drive, Suite 2 79 Tinton Falls, NJ 07724-2658, USA 80 Phone: +1 732 747 9987 81 Email: angela.chiu@celion.com 83 John Drake (Calient Networks) 84 5853 Rue Ferrari 85 San Jose, CA 95138, USA 86 Phone: +1 408 972-3720 87 Email: jdrake@calient.net 89 Yanhe Fan (Axiowave Networks, Inc.) 90 100 Nickerson Road 91 Marlborough, MA 01752, USA 92 Phone: +1 508 460-6969 Ext. 627 93 Email: yfan@axiowave.com 95 Michele Fontana (Alcatel) 97 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 2 98 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 100 Via Trento 30, 101 I-20059 Vimercate, Italy 102 Phone: +39 039 686-7053 103 Email: michele.fontana@netit.alcatel.it 105 Gert Grammel (Alcatel) 106 Via Trento 30, 107 I-20059 Vimercate, Italy 108 Phone: +39 039 686-7060 109 Email: gert.grammel@netit.alcatel.it 111 Juergen Heiles (Siemens AG) 112 Hofmannstr. 51 113 D-81379 Munich, Germany 114 Phone: +49 89 722-48664 115 Email: Juergen.Heiles@icn.siemens.de 117 Suresh Katukam (Cisco Systems) 118 1450 N. McDowell Blvd, 119 Petaluma, CA 94954-6515, USA 120 Email: skatukam@cisco.com 122 Kireeti Kompella (Juniper Networks, Inc.) 123 1194 N. Mathilda Ave. 124 Sunnyvale, CA 94089, USA 125 Email: kireeti@juniper.net 127 Jonathan P. Lang (Calient Networks) 128 25 Castilian 129 Goleta, CA 93117, USA 130 Email: jplang@calient.net 132 Fong Liaw (Solas Research) 133 Email: fongliaw@yahoo.com 135 Zhi-Wei Lin (Lucent) 136 101 Crawfords Corner Rd 137 Holmdel, NJ 07733-3030, USA 138 Phone: +1 732 949-5141 139 Email: zwlin@lucent.com 141 Ben Mack-Crane (Tellabs) 142 Email: ben.mack-crane@tellabs.com 144 Dimitrios Pendarakis (Tellium, Inc.) 145 2 Crescent Place 146 P.O. Box 901 147 Oceanport, NJ 07757-0901, USA 148 Phone: +1 732 923-4254 149 Email: dpendarakis@tellium.com 151 Mike Raftelis (White Rock Networks) 152 18111 Preston Road Suite 900 153 Dallas, TX 75252, USA 155 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 3 156 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 158 Phone: +1 972 588-3728 159 Email: mraftelis@WhiteRockNetworks.com 161 Bala Rajagopalan (Tellium, Inc.) 162 2 Crescent Place 163 P.O. Box 901 164 Oceanport, NJ 07757-0901, USA 165 Phone: +1 732 923 4237 166 Email: braja@tellium.com 168 Yakov Rekhter (Juniper Networks, Inc.) 169 1194 N. Mathilda Ave. 170 Sunnyvale, CA 94089, USA 171 Email: yakov@juniper.net 173 Debanjan Saha (Tellium) 174 2 Crescent Place 175 P.O. Box 901 176 Oceanport, NJ 07757-0901, USA 177 Phone: +1 732 923 4264 178 Email: dsaha@tellium.com 180 Vishal Sharma (Metanoia, Inc.) 181 335 Elan Village Lane 182 San Jose, CA 95134, USA 183 Phone: +1 408 943-1794 184 Email: vsharma87@yahoo.com 186 George Swallow (Cisco Systems, Inc.) 187 250 Apollo Drive 188 Chelmsford, MA 01824, USA 189 Voice: +1 978 244-8143 190 Email: swallow@cisco.com 192 Z. Bo Tang (Tellium, Inc.) 193 2 Crescent Place 194 P.O. Box 901 195 Oceanport, NJ 07757-0901, USA 196 Phone: +1 732 923-4231 197 Email: btang@tellium.com 199 Eve Varma (Lucent) 200 101 Crawfords Corner Rd 201 Holmdel, NJ 07733-3030, USA 202 Phone: +1 732 949-8559 203 Email: evarma@lucent.com 205 Yangguang Xu (Lucent) 206 21-2A41, 1600 Osgood Street 207 North Andover, MA 01845, USA 208 Email: xuyg@lucent.com 210 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 4 211 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 213 1. Introduction 215 As described in [GMPLS-ARCH], Generalized MPLS (GMPLS) extends 216 MPLS from supporting packet (Packet Switching Capable - PSC) 217 interfaces and switching to include support of four new classes of 218 interfaces and switching: Layer-2 Switch Capable (L2SC), Time- 219 Division Multiplex (TDM), Lambda Switch Capable (LSC) and Fiber- 220 Switch Capable (FSC). A functional description of the extensions 221 to MPLS signaling needed to support the new classes of interfaces 222 and switching is provided in [GMPLS-SIG]. [GMPLS-RSVP] describes 223 RSVP-TE specific formats and mechanisms needed to support all five 224 classes of interfaces, and CR-LDP extensions can be found in 225 [GMPLS-LDP]. This document presents details that are specific to 226 Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy 227 (SDH). Per [GMPLS-SIG], SONET/SDH specific parameters are carried 228 in the signaling protocol in traffic parameter specific objects. 230 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 231 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 232 in this document are to be interpreted as described in [RFC2119]. 234 The reader is assumed to be familiar with the terminology in ANSI 235 [T1.105], ITU-T [G.707] as well as [GMPLS-SIG], [GMPLS-RSVP] and 236 [GMPLS-LDP]. The following abbreviations are used in this document: 238 DCC: Data Communications Channel. 239 LOVC: Lower Order Virtual Container 240 HOVC: Higher Order Virtual Container 241 MS: Multiplex Section. 242 MSOH: Multiplex Section overhead. 243 POH: Path overhead. 244 RS: Regenerator Section. 245 RSOH: Regenerator section overhead. 246 SDH: Synchronous digital hierarchy. 247 SOH: Section overhead. 248 SONET: Synchronous Optical Network. 249 SPE: Synchronous Payload Envelope. 250 STM(-N): Synchronous Transport Module (-N) (SDH). 251 STS(-N): Synchronous Transport Signal-Level N (SONET). 252 VC-n: Virtual Container-n (SDH). 253 VTn: Virtual Tributary-n (SONET). 255 2. SONET and SDH Traffic Parameters 257 This section defines the GMPLS traffic parameters for SONET/SDH. 258 The protocol specific formats, for the SONET/SDH-specific RSVP-TE 259 objects and CR-LDP TLVs are described in sections 2.2 and 2.3 260 respectively. 262 These traffic parameters specify indeed a base set of capabilities 263 for SONET ANSI [T1.105] and SDH ITU-T [G.707] such as 264 concatenation and transparency. Other documents may further 265 enhance this set of capabilities in the future. For instance, 267 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 5 268 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 270 signaling for SDH over PDH ITU-T G.832 or sub-STM-0 ITU-T G.708 271 interfaces could be defined. 273 The traffic parameters defined hereafter MUST be used when 274 SONET/SDH is specified in the LSP Encoding Type field of a 275 Generalized Label Request [GMPLS-SIG]. 277 2.1. SONET/SDH Traffic Parameters 279 The traffic parameters for SONET/SDH are organized as follows: 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Signal Type | RCC | NCC | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | NVC | Multiplier (MT) | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Transparency (T) | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Profile (P) | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Annex 1 lists examples of SONET and SDH signal coding. 295 Signal Type (ST): 8 bits 297 This field indicates the type of Elementary Signal that 298 comprises the requested LSP. Several transforms can be applied 299 successively on the Elementary Signal to build the Final Signal 300 being actually requested for the LSP. 302 Each transform application is optional and must be ignored if 303 zero, except the Multiplier (MT) that cannot be zero and is 304 ignored if equal to one. 306 Transforms must be applied strictly in the following order: 308 - First, contiguous concatenation (by using the RCC and NCC 309 fields) can be optionally applied on the Elementary Signal, 310 resulting in a contiguously concatenated signal. 311 - Second, virtual concatenation (by using the NVC field) can 312 be optionally applied on the Elementary Signal resulting in 313 a virtually concatenated signal. 314 - Third, some transparency (by using the Transparency field) 315 can be optionally specified when requesting a frame as 316 signal rather than an SPE or VC based signal. 317 - Fourth, a multiplication (by using the Multiplier field) can be 318 optionally applied either directly on the Elementary Signal, or 319 on the contiguously concatenated signal obtained from the first 320 phase, or on the virtually concatenated signal obtained from 321 the second phase, or on these signals combined with some 322 transparency. 324 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 6 325 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 327 Permitted Signal Type values for SONET/SDH are: 329 Value Type (Elementary Signal) 330 ----- ------------------------ 331 1 VT1.5 SPE / VC-11 332 2 VT2 SPE / VC-12 333 3 VT3 SPE 334 4 VT6 SPE / VC-2 335 5 STS-1 SPE / VC-3 336 6 STS-3c SPE / VC-4 337 7 STS-1 / STM-0 (only when requesting transparency) 338 8 STS-3 / STM-1 (only when requesting transparency) 339 9 STS-12 / STM-4 (only when requesting transparency) 340 10 STS-48 / STM-16 (only when requesting transparency) 341 11 STS-192 / STM-64 (only when requesting transparency) 342 12 STS-768 / STM-256 (only when requesting transparency) 344 A dedicated signal type is assigned to a SONET STS-3c SPE instead 345 of coding it as a contiguous concatenation of three STS-1 SPEs. 346 This is done in order to provide easy interworking between SONET 347 and SDH signaling. 349 Appendix 1 adds one signal type (optional) to the above values. 351 Requested Contiguous Concatenation (RCC): 8 bits 353 This field is used to request the optional SONET/SDH contiguous 354 concatenation of the Elementary Signal. 356 This field is a vector of flags. Each flag indicates the 357 support of a particular type of contiguous concatenation. 358 Several flags can be set at the same time to indicate a choice. 360 These flags allow an upstream node to indicate to a downstream 361 node the different types of contiguous concatenation that it 362 supports. However, the downstream node decides which one to use 363 according to its own rules. 365 A downstream node receiving simultaneously more than one flag 366 chooses a particular type of contiguous concatenation, if any 367 supported, and based on criteria that are out of this document 368 scope. A downstream node that doesn�t support any of the 369 concatenation types indicated by the field must refuse the LSP 370 request. In particular, it must refuse the LSP request if it 371 doesn�t support contiguous concatenation at all. 373 When several flags have been set, the upstream node retrieves 374 the (single) type of contiguous concatenation the downstream 375 node has selected by looking at the position indicated by the 376 first label and the number of label(s) as returned by the 377 downstream node (see also Section 3). 379 The entire field is set to zero to indicate that no contiguous 380 concatenation is requested at all (default value). A non-zero 382 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 7 383 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 385 field indicates that some contiguous concatenation is 386 requested. 388 The following flag is defined: 390 Flag 1 (bit 1): Standard contiguous concatenation. 392 Flag 1 indicates that the standard SONET/SDH contiguous 393 concatenation as defined in [T1.105]/[G.707] is supported. Note 394 that bit 1 is the low order bit. Other flags are reserved for 395 extensions, if not used they must be set to zero when sent, and 396 should be ignored when received. 398 See note 1 hereafter in the section on the NCC about the SONET 399 contiguous concatenation of STS-1 SPEs when the number of 400 components is a multiple of three. 402 Number of Contiguous Components (NCC): 16 bits 404 This field indicates the number of identical SONET SPEs/SDH VCs 405 (i.e. Elementary Signal) that are requested to be concatenated, 406 as specified in the RCC field. 408 Note 1: when requesting a SONET STS-Nc SPE with N=3*X, the 409 Elementary Signal to use must always be an STS-3c SPE signal 410 type and the value of NCC must always be equal to X. This 411 allows also facilitating the interworking between SONET and 412 SDH. In particular, it means that the contiguous concatenation 413 of three STS-1 SPEs can not be requested because according to 414 this specification, this type of signal must be coded using the 415 STS-3c SPE signal type. 417 Note 2: when requesting a transparent STS-N/STM-N signal 418 limited to a single contiguously concatenated STS-Nc_SPE/VC-4- 419 Nc, the signal type must be STS-N/STM-N, RCC with flag 1 and 420 NCC set to 1. 422 The NCC value must be consistent with the type of contiguous 423 concatenation being requested in the RCC field. In particular, 424 this field is irrelevant if no contiguous concatenation is 425 requested (RCC = 0), in that case it must be set to zero when 426 sent, and should be ignored when received. A RCC value 427 different from 0 must imply a number of contiguous components 428 greater than 1. 430 Number of Virtual Components (NVC): 16 bits 432 This field indicates the number of signals that are requested 433 to be virtually concatenated. These signals are all of the same 434 type by definition. They are Elementary Signal SPEs/VCs for 435 which signal types are defined in this document, i.e. 436 VT1.5_SPE/VC-11, VT2_SPE/VC-12, VT3_SPE, VT6_SPE/VC-2, STS- 437 1_SPE/VC-3 or STS-3c_SPE/VC-4. 439 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 8 440 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 442 This field is set to 0 (default value) to indicate that no 443 virtual concatenation is requested. 445 Multiplier (MT): 16 bits 447 This field indicates the number of identical signals that are 448 requested for the LSP, i.e. that form the Final Signal. These 449 signals can be either identical Elementary Signals, or 450 identical contiguously concatenated signals, or identical 451 virtually concatenated signals. Note that all these signals 452 belong thus to the same LSP. 454 The distinction between the components of multiple virtually 455 concatenated signals is done via the order of the labels that 456 are specified in the signaling. The first set of labels must 457 describe the first component (set of individual signals 458 belonging to the first virtual concatenated signal), the second 459 set must describe the second component (set of individual 460 signals belonging to the second virtual concatenated signal) 461 and so on. 463 This field is set to one (default value) to indicate that exactly 464 one instance of a signal is being requested. Intermediate and 465 egress nodes MUST verify that the node itself and the interfaces 466 on which the LSP will be established can support the requested 467 multiplier value. If the requested values can not be supported, 468 the receiver node MUST generate a PathErr/NOTIFICATION message 469 (see Section 2.2/2.3, respectively). 471 Zero is an invalid value. If received, the node MUST generate a 472 PathErr/NOTIFICATION message (see Section 2.2/2.3, respectively). 474 Note 1: when requesting a transparent STS-N/STM-N signal limited 475 to a single contiguously concatenated STS-Nc-SPE/VC-4-Nc, the 476 multiplier field must be equal to 1 (only valid value). 478 Transparency (T): 32 bits 480 This field is a vector of flags that indicates the type of 481 transparency being requested. Several flags can be combined to 482 provide different types of transparency. Not all combinations 483 are necessarily valid. The default value for this field is 484 zero, i.e. no transparency requested. 486 Transparency, as defined from the point of view of this 487 signaling specification, is only applicable to the fields in 488 the SONET/SDH frame overheads. In the SONET case, these are the 489 fields in the Section Overhead (SOH), and the Line Overhead 490 (LOH). In the SDH case, these are the fields in the Regenerator 491 Section Overhead (RSOH), the Multiplex Section overhead (MSOH), 492 and the pointer fields between the two. With SONET, the pointer 493 fields are part of the LOH. 495 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 9 496 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 498 Note as well that transparency is only applicable when using 499 the following Signal Types: STS-1/STM-0, STS-3/STM-1, STS-12/ 500 STM-4, STS-48/STM-16, STS-192/STM-64 and STS-768/STM-256. At 501 least one transparency type must be specified when requesting 502 such a signal type. 504 Transparency indicates precisely which fields in these 505 overheads must be delivered unmodified at the other end of the 506 LSP. An ingress LSR requesting transparency will pass these 507 overhead fields that must be delivered to the egress LSR 508 without any change. From the ingress and egress LSRs point of 509 views, these fields must be seen as unmodified. 511 Transparency is not applied at the interfaces with the 512 initiating and terminating LSRs, but is only applied between 513 intermediate LSRs. 515 The transparency field is used to request an LSP that supports 516 the requested transparency type; it may also be used to setup 517 the transparency process to be applied at each intermediate 518 LSR. 520 The different transparency flags are the following: 522 Flag 1 (bit 1): Section/Regenerator Section layer. 523 Flag 2 (bit 2): Line/Multiplex Section layer. 525 Where bit 1 is the low order bit. Others flags are reserved, they 526 should be set to zero when sent, and should be ignored when 527 received. A flag is set to one to indicate that the corresponding 528 transparency is requested. 530 Intermediate and egress nodes MUST verify that the node itself and 531 the interfaces on which the LSP will be established can support 532 the requested transparency. If the requested flags can not be 533 supported, the receiver node MUST generate a PathErr/ NOTIFICATION 534 message (see Section 2.2/2.3, respectively). 536 Section/Regenerator Section layer transparency means that the 537 entire frames must be delivered unmodified. This implies that 538 pointers cannot be adjusted. When using Section/Regenerator 539 Section layer transparency all other flags must be ignored. 541 Line/Multiplex Section layer transparency means that the 542 LOH/MSOH must be delivered unmodified. This implies that 543 pointers cannot be adjusted. 545 Profile (P): 32 bits 547 This field is intended to indicate particular capabilities that 548 must be supported for the LSP, for example monitoring 549 capabilities. 551 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 10 552 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 554 No standard profile is currently defined and this field SHOULD 555 be set to zero when transmitted and SHOULD be ignored when 556 received. 558 In the future TLV based extensions may be created. 560 2.2. RSVP-TE Details 562 For RSVP-TE, the SONET/SDH traffic parameters are carried in the 563 SONET/SDH SENDER_TSPEC and FLOWSPEC objects. The same format is 564 used both for SENDER_TSPEC object and FLOWSPEC objects. The 565 content of the objects is defined above in Section 2.1. The 566 objects have the following class and type: 568 For SONET ANSI T1.105 and SDH ITU-T G.707: 570 SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = TBA (by IANA) 571 SONET/SDH FLOWSPEC object: Class = 9, C-Type = TBA (by IANA) 573 There is no Adspec associated with the SONET/SDH SENDER_TSPEC. 574 Either the Adspec is omitted or an int-serv Adspec with the 575 Default General Characterization Parameters and Guaranteed Service 576 fragment is used, see [RFC2210]. 578 For a particular sender in a session the contents of the FLOWSPEC 579 object received in a Resv message SHOULD be identical to the 580 contents of the SENDER_TSPEC object received in the corresponding 581 Path message. If the objects do not match, a ResvErr message with 582 a "Traffic Control Error/Bad Flowspec value" error SHOULD be 583 generated. 585 Intermediate and egress nodes MUST verify that the node itself and 586 the interfaces on which the LSP will be established can support 587 the requested Signal Type, RCC, NCC, NVC and Multiplier (as 588 defined in Section 2.1). If the requested value(s) can not be 589 supported, the receiver node MUST generate a PathErr message with 590 a "Traffic Control Error/ Service unsupported" indication (see 591 [RFC2205]). 593 In addition, if the MT field is received with a zero value, the 594 node MUST generate a PathErr message with a "Traffic Control 595 Error/Bad Tspec value" indication (see [RFC2205]). 597 Intermediate nodes MUST also verify that the node itself and the 598 interfaces on which the LSP will be established can support the 599 requested Transparency (as defined in Section 2.1). If the 600 requested value(s) can not be supported, the receiver node MUST 601 generate a PathErr message with a "Traffic Control Error/Service 602 unsupported" indication (see [RFC2205]). 604 2.3. CR-LDP Details 606 For CR-LDP, the SONET/SDH traffic parameters are carried in the 607 SONET/SDH Traffic Parameters TLV. The content of the TLV is 609 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 11 610 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 612 defined above in Section 2.1. The header of the TLV has the 613 following format: 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 |U|F| Type | Length | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 The type field for the SONET/SDH Traffic Parameters TLV is: TBA 622 (by IANA). 624 Intermediate and egress nodes MUST verify that the node itself and 625 the interfaces on which the LSP will be established can support 626 the requested Signal Type, RCC, NCC, NVC and Multiplier (as 627 defined in Section 2.1). If the requested value(s) can not be 628 supported, the receiver node MUST generate a NOTIFICATION message 629 with a "Resource Unavailable" status code (see [RFC3212]). 631 In addition, if the MT field is received with a zero value, the 632 node MUST generate a NOTIFICATION message with a "Resource 633 Unavailable" status code (see [RFC3212]). 635 Intermediate nodes MUST also verify that the node itself and the 636 interfaces on which the LSP will be established can support the 637 requested Transparency (as defined in Section 2.1). If the 638 requested value(s) can not be supported, the receiver node MUST 639 generate a NOTIFICATION message with a "Resource Unavailable" 640 status code (see [RFC3212]). 642 3. SONET and SDH Labels 644 SONET and SDH each define a multiplexing structure. Both 645 structures are trees whose roots are respectively an STS-N or an 646 STM-N; and whose leaves are the signals that can be transported 647 via the time-slots and switched between time-slots within an 648 ingress port and time-slots within an egress port, i.e. a VTx SPE, 649 an STS-x SPE or a VC-x. A SONET/SDH label will identify the exact 650 position (i.e. first time-slot) of a particular VTx SPE, STS-x SPE 651 or VC-x signal in a multiplexing structure. SONET and SDH labels 652 are carried in the Generalized Label per [GMPLS-RSVP] and [GMPLS- 653 LDP]. 655 Note that by time-slots we mean the time-slots as they appear 656 logically and sequentially in the multiplex, not as they appear 657 after any possible interleaving. 659 These multiplexing structures will be used as naming trees to 660 create unique multiplex entry names or labels. The same format of 661 label is used for SONET and SDH. As explained in [GMPLS-SIG], a 662 label does not identify the "class" to which the label belongs. 663 This is implicitly determined by the link on which the label is 664 used. 666 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 12 667 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 669 In case of signal concatenation or multiplication, a list of 670 labels can appear in the Label field of a Generalized Label. 672 In case of contiguous concatenation, only one label appears in the 673 Label field. This label identifies the lowest time-slot occupied 674 by the contiguously concatenated signal. By lowest time-slot we 675 mean the one having the lowest label (value) when compared as 676 integer values, i.e. the time-slot occupied by the first component 677 signal of the concatenated signal encountered when descending the 678 tree. 680 In case of virtual concatenation, the explicit ordered list of all 681 labels in the concatenation is given. Each label indicates the 682 first time-slot occupied by a component of the virtually 683 concatenated signal. The order of the labels must reflect the 684 order of the payloads to concatenate (not the physical order of 685 time-slots). The above representation limits virtual concatenation 686 to remain within a single (component) link; it imposes as such a 687 restriction compared to the ANSI [T1.105]/ITU-T [G.707] 688 recommendations. 690 The standard definition for virtual concatenation allows each 691 virtual concatenation components to travel over diverse paths. 692 Within GMPLS, virtual concatenation components must travel over 693 the same (component) link if they are part of the same LSP. This 694 is due to the way that labels are bound to a (component) link. 695 Note however, that the routing of components on different paths is 696 indeed equivalent to establishing different LSPs, each one having 697 its own route. Several LSPs can be initiated and terminated 698 between the same nodes and their corresponding components can then 699 be associated together (i.e. virtually concatenated). 701 In case of multiplication (i.e. using the multiplier transform), 702 the explicit ordered list of all labels that take part in the 703 Final Signal is given. In case of multiplication of virtually 704 concatenated signals, the first set of labels indicates the time- 705 slots occupied by the first virtually concatenated signal, the 706 second set of labels indicates the time-slots occupied by the 707 second virtually concatenated signal, and so on. The above 708 representation limits multiplication to remain within a single 709 (component) link. 711 The format of the label for SONET and/or SDH TDM-LSR link is: 713 0 1 2 3 714 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 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | S | U | K | L | M | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 This is an extension of the numbering scheme defined in [G.707] 720 sections 7.3.7 to 7.3.13, i.e. the (K, L, M) numbering. Note that 721 the higher order numbering scheme defined in [G.707] sections 722 7.3.1 to 7.3.6 is not used here. 724 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 13 725 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 727 Each letter indicates a possible branch number starting at the 728 parent node in the multiplex structure. Branches are considered as 729 numbered in increasing order, starting from the top of the 730 multiplexing structure. The numbering starts at 1, zero is used to 731 indicate a non-significant or ignored field. 733 When a field is not significant or ignored in a particular context 734 it MUST be set to zero when transmitted, and MUST be ignored when 735 received. 737 When a hierarchy of SONET/SDH LSPs is used, a higher order LSP 738 with a given bandwidth can be used to carry lower order LSPs. 739 Remember here that a higher order LSP is established through a 740 SONET/SDH higher order path layer network and a lower order LSP, 741 through a SONET/SDH lower order path layer network (see also ITU-T 742 G.803, Section 3 for the corresponding definitions). In this 743 context, the higher order SONET/SDH LSP behaves as a "virtual 744 link" with a given bandwidth (e.g. VC-3), it may also be used as a 745 Forwarding Adjacency. A lower order SONET/SDH LSP can be 746 established through that higher order LSP. Since a label is local 747 to a (virtual) link, the highest part of that label (i.e. the S, U 748 and K fields) is non-significant and is set to zero, i.e. the 749 label is "0,0,0,L,M". Similarly, if the structure of the lower 750 order LSP is unknown or not relevant, the lowest part of that 751 label (i.e. the L and M fields) is non-significant and is set to 752 zero, i.e. the label is "S,U,K,0,0". 754 For instance, a VC-3 LSP can be used to carry lower order LSPs. In 755 that case the labels allocated between the two ends of the VC-3 756 LSP for the lower order LSPs will have S, U and K set to zero, 757 i.e., non-significant, while L and M will be used to indicate the 758 signal allocated in that VC-3. 760 In case of tunneling such as VC-4 containing VC-3 containing VC- 761 12/VC-11 where the SUKLM structure is not adequate to represent 762 the full signal structure, a hierarchical approach must be used, 763 i.e. per layer network signaling. 765 The possible values of S, U, K, L and M are defined as follows: 767 1. S=1->N is the index of a particular STS-3/AUG-1 inside an 768 STS-N/STM-N multiplex. S is only significant for SONET STS-N 769 (N>1) and SDH STM-N (N>0). S must be 0 and ignored for STS-1 and 770 STM-0. 772 2. U=1->3 is the index of a particular STS-1_SPE/VC-3 within an 773 STS-3/AUG-1. U is only significant for SONET STS-N (N>1) and SDH 774 STM-N (N>0). U must be 0 and ignored for STS-1 and STM-0. 776 3. K=1->3 is the index of a particular TUG-3 within a VC-4. K is 777 only significant for an SDH VC-4 structured in TUG-3s. K must be 778 0 and ignored in all other cases. 780 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 14 781 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 783 4. L=1->7 is the index of a particular VT_Group/TUG-2 within an 784 STS-1_SPE/TUG-3 or VC-3. L must be 0 and ignored in all other 785 cases. 787 5. M is the index of a particular VT1.5_SPE/VC-11, VT2_SPE/VC-12 788 or VT3_SPE within a VT_Group/TUG-2. M=1->2 indicates a specific 789 VT3 SPE inside the corresponding VT Group, these values MUST NOT 790 be used for SDH since there is no equivalent of VT3 with SDH. 791 M=3->5 indicates a specific VT2_SPE/VC-12 inside the 792 corresponding VT_Group/TUG-2. M=6->9 indicates a specific 793 VT1.5_SPE/VC-11 inside the corresponding VT_Group/TUG-2. 795 Note that a label always has to be interpreted according the 796 SONET/SDH traffic parameters, i.e. a label by itself does not 797 allow knowing which signal is being requested (a label is 798 context sensitive). 800 The S encoding is summarized in the following table: 802 S SDH SONET 803 ------------------------------------------------ 804 0 other other 805 1 1st AUG-1 1st STS-3 806 2 2nd AUG-1 2nd STS-3 807 3 3rd AUG-1 3rd STS-3 808 4 4rd AUG-1 4rd STS-3 809 : : : 810 N Nth AUG-1 Nth STS-3 812 The U encoding is summarized in the following table: 814 U SDH AUG-1 SONET STS-3 815 ------------------------------------------------- 816 0 other other 817 1 1st VC-3 1st STS-1 SPE 818 2 2nd VC-3 2nd STS-1 SPE 819 3 3rd VC-3 3rd STS-1 SPE 821 The K encoding is summarized in the following table: 823 K SDH VC-4 824 --------------- 825 0 other 826 1 1st TUG-3 827 2 2nd TUG-3 828 3 3rd TUG-3 830 The L encoding is summarized in the following table: 832 L SDH TUG-3 SDH VC-3 SONET STS-1 SPE 833 ------------------------------------------------- 834 0 other other other 835 1 1st TUG-2 1st TUG-2 1st VTG 836 2 2nd TUG-2 2nd TUG-2 2nd VTG 838 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 15 839 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 841 3 3rd TUG-2 3rd TUG-2 3rd VTG 842 4 4th TUG-2 4th TUG-2 4th VTG 843 5 5th TUG-2 5th TUG-2 5th VTG 844 6 6th TUG-2 6th TUG-2 6th VTG 845 7 7th TUG-2 7th TUG-2 7th VTG 847 The M encoding is summarized in the following table: 849 M SDH TUG-2 SONET VTG 850 ------------------------------------------------- 851 0 other other 852 1 - 1st VT3 SPE 853 2 - 2nd VT3 SPE 854 3 1st VC-12 1st VT2 SPE 855 4 2nd VC-12 2nd VT2 SPE 856 5 3rd VC-12 3rd VT2 SPE 857 6 1st VC-11 1st VT1.5 SPE 858 7 2nd VC-11 2nd VT1.5 SPE 859 8 3rd VC-11 3rd VT1.5 SPE 860 9 4th VC-11 4th VT1.5 SPE 862 Examples of labels: 864 Example 1: the label for the STS-3c_SPE/VC-4 in the Sth STS-3/AUG- 865 1 is: S>0, U=0, K=0, L=0, M=0. 867 Example 2: the label for the VC-3 within the Kth-1 TUG-3 within 868 the VC-4 in the Sth AUG-1 is: S>0, U=0, K>0, L=0, M=0. 870 Example 3: the label for the Uth-1 STS-1_SPE/VC-3 within the Sth 871 STS-3/AUG-1 is: S>0, U>0, K=0, L=0, M=0. 873 Example 4: the label for the VT6/VC-2 in the Lth-1 VT Group/TUG-2 874 in the Uth-1 STS-1_SPE/VC-3 within the Sth STS-3/AUG-1 is: S>0, 875 U>0, K=0, L>0, M=0. 877 Example 5: the label for the 3rd VT1.5_SPE/VC-11 in the Lth-1 VT 878 Group/TUG-2 within the Uth-1 STS-1_SPE/VC-3 within the Sth STS- 879 3/AUG-1 is: S>0, U>0, K=0, L>0, M=8. 881 Example 6: the label for the STS-12c/VC-4-4c which uses the 9th 882 STS-3/AUG-1 as its first timeslot is: S=9, U=0, K=0, L=0, M=0. 884 In case of contiguous concatenation, the label that is used is the 885 lowest label (value) of the contiguously concatenated signal as 886 explained before. The higher part of the label indicates where the 887 signal starts and the lowest part is not significant. 889 In case of STM-0/STS-1, the values of S, U and K must be equal to 890 zero according to the field coding rules. For instance, when 891 requesting a VC-3 in an STM-0 the label is S=0, U=0, K=0, L=0, 892 M=0. When requesting a VC-11 in a VC-3 in an STM-0 the label is 893 S=0, U=0, K=0, L>0, M=6..9. 895 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 16 896 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 898 When a transparent STS-3*N/STM-N (N=1, 4, 16, 64, 256) is 899 requested, the label is not applicable and is set to zero. 901 4. Acknowledgments 903 Valuable comments and input were received from the CCAMP mailing 904 list where outstanding discussions took place. 906 5. Security Considerations 908 This draft introduces no new security considerations to either 909 [GMPLS-RSVP] or [GMPLS-LDP]. GMPLS security is described in 910 section 11 of [GMPLS-SIG], in [RFC3209] and in [RFC3212]. 912 6. IANA Considerations 914 Three values have to be defined by IANA for this document: 915 two RSVP C-Types in registry: 916 http://www.iana.org/assignments/rsvp-parameters 917 and one LDP TLV Type in registry: 918 http://www.iana.org/assignments/ldp-namespaces 920 - A SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = TBA (see 921 section 2.2). 922 - A SONET/SDH FLOWSPEC object: Class = 9, C-Type = TBA (see 923 section 2.2). 924 - A type field for the SONET/SDH Traffic Parameters TLV (see 925 section 2.3). 927 7. Intellectual Property Notice 929 The IETF takes no position regarding the validity or scope of any 930 intellectual property or other rights that might be claimed to 931 pertain to the implementation or use of the technology described in 932 this document or the extent to which any license under such rights 933 might or might not be available; neither does it represent that it 934 has made any effort to identify any such rights. Information on the 935 IETF's procedures with respect to rights in standards-track and 936 standards-related documentation can be found in BCP-11. Copies of 937 claims of rights made available for publication and any assurances 938 of licenses to be made available, or the result of an attempt made 939 to obtain a general license or permission for the use of such 940 proprietary rights by implementors or users of this specification 941 can be obtained from the IETF Secretariat. 943 The IETF invites any interested party to bring to its attention any 944 copyrights, patents or patent applications, or other proprietary 945 rights which may cover technology that may be required to practice 946 this standard. Please address the information to the IETF Executive 947 Director. 949 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 17 950 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 952 8. References 954 8.1 Normative References 956 [G.707] ITU-T Recommendation G.707, �Network Node Interface 957 for the Synchronous Digital Hierarchy�, October 2000. 959 [GMPLS-ARCH] Mannie, E., Papadimitriou D., et al., "Generalized 960 Multiprotocol Label Switching Architecture", 961 Internet Draft, Work in progress, 962 draft-ietf-ccamp-gmpls-architecture-03.txt, 963 August 2002. 965 [GMPLS-LDP] Berger, L. et al., "Generalized MPLS Signaling - CR- 966 LDP Extensions", 967 Internet Draft, Work in progress, 968 draft-ietf-mpls-generalized-cr-ldp-06.txt, 969 April 2002. 971 [GMPLS-RSVP] Berger, L. et al., "Generalized MPLS Signaling � 972 RSVP-TE Extensions", 973 Internet Draft, Work in progress, 974 draft-ietf-mpls-generalized-rsvp-te-07.txt, 975 April 2002. 977 [GMPLS-SIG] Berger, L. et al., "Generalized MPLS - Signaling 978 Functional Description", 979 Internet Draft, Work in progress, 980 draft-ietf-mpls-generalized-signaling-08.txt, 981 April 2002. 983 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 984 Requirement Levels", BCP 14, RFC 2119, March 1997. 986 [RFC2205] Braden, R., et al., "Resource ReSerVation Protocol 987 (RSVP) -- Version 1 Functional Specification", RFC 988 2205, September 1997. 990 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 991 Services," RFC 2210, September 1997. 993 [RFC3209] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for 994 LSP Tunnels", RFC 3209, December 2001. 996 [RFC3212] Jamoussi, B., et al., "Constraint-Based LSP Setup using 997 LDP", RFC 3212, January 2002. 999 [T1.105] "Synchronous Optical Network (SONET): Basic 1000 Description Including Multiplex Structure, Rates, and 1001 Formats", ANSI T1.105, October 2000. 1003 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 18 1004 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 1006 9. Author�s Addresses 1008 Eric Mannie (KPNQwest) 1009 Terhulpsesteenweg 6A 1010 1560 Hoeilaart - Belgium 1011 Phone: +32 2 658-5652 1012 Mobile: +32 496 585652 1013 Fax: +32 2 658-5118 1014 Email: eric.mannie@kpnqwest.com 1016 Dimitri Papadimitriou (Alcatel) 1017 Francis Wellesplein 1, 1018 B-2018 Antwerpen, Belgium 1019 Phone: +32 3 240-8491 1020 Email: dimitri.papadimitriou@alcatel.be 1022 10. Full Copyright Statement 1024 "Copyright (C) The Internet Society (date). All Rights Reserved. 1026 This document and translations of it may be copied and furnished to 1027 others, and derivative works that comment on or otherwise explain it 1028 or assist in its implementation may be prepared, copied, published 1029 and distributed, in whole or in part, without restriction of any 1030 kind, provided that the above copyright notice and this paragraph 1031 are included on all such copies and derivative works. However, this 1032 document itself may not be modified in any way, such as by removing 1033 the copyright notice or references to the Internet Society or other 1034 Internet organizations, except as needed for the purpose of 1035 developing Internet standards in which case the procedures for 1036 copyrights defined in the Internet Standards process must be 1037 followed, or as required to translate it into languages other than 1038 English. 1040 The limited permissions granted above are perpetual and will not be 1041 revoked by the Internet Society or its successors or assigns. 1043 This document and the information contained herein is provided on an 1044 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1045 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1046 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1047 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1048 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1050 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 19 1051 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 1053 Appendix 1 - Signal Type Values Extension for VC-3 1055 This appendix defines the following optional additional Signal 1056 Type value for the Signal Type field of section 2.1: 1058 Value Type 1059 ----- --------------------- 1060 20 "VC-3 via AU-3 at the end" 1062 According to the ITU-T [G.707] recommendation a VC-3 in the TU- 1063 3/TUG-3/VC-4/AU-4 branch of the SDH multiplex cannot be structured 1064 in TUG-2s, however a VC-3 in the AU-3 branch can be. In addition, 1065 a VC-3 could be switched between the two branches if required. 1067 A VC-3 circuit could be terminated on an ingress interface of an 1068 LSR (e.g. forming a VC-3 forwarding adjacency). This LSR could 1069 then want to demultiplex this VC-3 and switch internal low order 1070 LSPs. For implementation reasons, this could be only possible if 1071 the LSR receives the VC-3 in the AU-3 branch. E.g. for an LSR not 1072 able to switch internally from a TU-3 branch to an AU-3 branch on 1073 its incoming interface before demultiplexing and then switching 1074 the content with its switch fabric. 1076 In that case it is useful to indicate that the VC-3 LSP must be 1077 terminated at the end in the AU-3 branch instead of the TU-3 1078 branch. 1080 This is achieved by using the "VC-3 via AU-3 at the end" signal 1081 type. This information can be used, for instance, by the 1082 penultimate LSR to switch an incoming VC-3 received in any branch 1083 to the AU-3 branch on the outgoing interface to the destination 1084 LSR. 1086 The "VC-3 via AU-3 at the end" signal type does not imply that the 1087 VC-3 must be switched via the AU-3 branch at some other places in 1088 the network. The VC-3 signal type just indicates that a VC-3 in 1089 any branch is suitable. 1091 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 20 1092 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 1094 Annex 1 - Examples 1096 This annex defines examples of SONET and SDH signal coding. Their 1097 objective is to help the reader to understand how works the traffic 1098 parameter coding and not to give examples of typical SONET or SDH 1099 signals. 1101 As stated above, signal types are Elementary Signals to which 1102 successive concatenation, multiplication and transparency 1103 transforms can be applied to obtain Final Signals. 1105 1. A VC-4 signal is formed by the application of RCC with value 0, 1106 NCC with value 0, NVC with value 0, MT with value 1 and T with 1107 value 0 to a VC-4 Elementary Signal. 1109 2. A VC-4-7v signal is formed by the application of RCC with value 1110 0, NCC with value 0, NVC with value 7 (virtual concatenation of 7 1111 components), MT with value 1 and T with value 0 to a VC-4 1112 Elementary Signal. 1114 3. A VC-4-16c signal is formed by the application of RCC with flag 1115 1 (standard contiguous concatenation), NCC with value 16, NVC with 1116 value 0, MT with value 1 and T with value 0 to a VC-4 Elementary 1117 Signal. 1119 4. An STM-16 signal with Multiplex Section layer transparency is 1120 formed by the application of RCC with value 0, NCC with value 0, 1121 NVC with value 0, MT with value 1 and T with flag 2 to an STM-16 1122 Elementary Signal. 1124 5. An STM-4 signal with Multiplex Section layer transparency is 1125 formed by the application of RCC with flag 0, NCC with value 0, 1126 NVC with value 0, MT with value 1 and T with flag 2 applied to an 1127 STM-4 Elementary Signal. 1129 6. An STM-256 signal with Multiplex Section layer transparency is 1130 formed by the application of RCC with flag 0, NCC with value 0, 1131 NVC with value 0, MT with value 1 and T with flag 2 applied to an 1132 STM-256 Elementary Signal. 1134 7. An STS-1 SPE signal is formed by the application of RCC with 1135 value 0, NCC with value 0, NVC with value 0, MT with value 1 and T 1136 with value 0 to an STS-1 SPE Elementary Signal. 1138 8. An STS-3c SPE signal is formed by the application of RCC with 1139 value 0 (no contiguous concatenation), NCC with value 0, NVC with 1140 value 0, MT with value 1 and T with value 0 to an STS-3c SPE 1141 Elementary Signal. 1143 9. An STS-48c SPE signal is formed by the application of RCC with 1144 flag 1 (standard contiguous concatenation), NCC with value 16, NVC 1145 with value 0, MT with value 1 and T with value 0 to an STS-3c SPE 1146 Elementary Signal. 1148 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 21 1149 draft-ietf-ccamp-gmpls-sonet-sdh-06.txt August 2002 1151 10. An STS-1-3v SPE signal is formed by the application of RCC 1152 with value 0, NVC with value 3 (virtual concatenation of 3 1153 components), MT with value 1 and T with value 0 to an STS-1 SPE 1154 Elementary Signal. 1156 11. An STS-3c-9v SPE signal is formed by the application of RCC 1157 with value 0, NCC with value 0, NVC with value 9 (virtual 1158 concatenation of 9 STS-3c), MT with value 1 and T with value 0 to 1159 an STS-3c SPE Elementary Signal. 1161 12. An STS-12 signal with Section layer (full) transparency is 1162 formed by the application of RCC with value 0, NVC with value 0, 1163 MT with value 1 and T with flag 1 to an STS-12 Elementary Signal. 1165 13. 3 x STS-768c SPE signal is formed by the application of RCC 1166 with flag 1, NCC with value 256, NVC with value 0, MT with value 1167 3, and T with value 0 to an STS-3c SPE Elementary Signal. 1169 14. 5 x VC-4-13v composed signal is formed by the application of 1170 RCC with value 0, NVC with value 13, MT with value 5 and T with 1171 value 0 to a VC-4 Elementary Signal. 1173 The encoding of these examples is summarized in the following 1174 table: 1176 Signal ST RCC NCC NVC MT T 1177 -------------------------------------------------------- 1178 VC-4 6 0 0 0 1 0 1179 VC-4-7v 6 0 0 7 1 0 1180 VC-4-16c 6 1 16 0 1 0 1181 STM-16 MS transparent 10 0 0 0 1 2 1182 STM-4 MS transparent 9 0 0 0 1 2 1183 STM-256 MS transparent 12 0 0 0 1 2 1184 STS-1 SPE 5 0 0 0 1 0 1185 STS-3c SPE 6 0 0 0 1 0 1186 STS-48c SPE 6 1 16 0 1 0 1187 STS-1-3v SPE 5 0 0 3 1 0 1188 STS-3c-9v SPE 6 0 0 9 1 0 1189 STS-12 Section transparent 9 0 0 0 1 1 1190 3 x STS-768c SPE 6 1 256 0 3 0 1191 5 x VC-4-13v 6 0 0 13 5 0 1193 E.Mannie & D.Papadimitriou Editors - Internet-Draft � Feb. 2003 22