idnits 2.17.1 draft-ietf-ccamp-rfc3946bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1166. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1184. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1190. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1153), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 19) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (December 2005) is 6699 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' Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Mannie 3 Internet Draft Consultant 4 Replaces RFC 3946 D. Papadimitriou 5 Category: Standard Track Alcatel 6 Expiration Date: May 2006 7 December 2005 9 Generalized Multi-Protocol Label Switching (GMPLS) Extensions 10 for Synchronous Optical Network (SONET) 11 and Synchronous Digital Hierarchy (SDH) Control 13 draft-ietf-ccamp-rfc3946bis-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). All Rights Reserved. 42 Abstract 44 This document provides minor clarification to RFC 3946. 46 This document is a companion to the Generalized Multi-Protocol 47 Label Switching (GMPLS) signaling. It defines the Synchronous 48 Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) 49 technology specific information needed when using GMPLS signaling. 51 E.Mannie & D.Papadimitriou (Editors) 1 52 Table of Contents 54 1. Introduction .............................................. 2 55 2. SONET and SDH Traffic Parameters .......................... 2 56 2.1. SONET/SDH Traffic Parameters ........................ 3 57 2.2. RSVP-TE Details ..................................... 9 58 2.3. CR-LDP Details ...................................... 9 59 3. SONET and SDH Labels ...................................... 10 60 4. Acknowledgments ........................................... 15 61 5. Security Considerations ................................... 16 62 6. IANA Considerations ....................................... 16 63 7. References ................................................ 16 64 7.1. Normative References ................................ 16 65 Appendix 1 - Signal Type Values Extension for VC-3 ............ 18 66 Annex 1 - Examples ............................................ 18 67 Contributors .................................................. 21 68 Authors' Addresses ............................................ 25 69 Full Copyright Statement ...................................... 26 71 1. Introduction 73 As described in [RFC3945], Generalized MPLS (GMPLS) extends MPLS 74 from supporting packet (Packet Switching Capable - PSC) interfaces 75 and switching to include support of four new classes of interfaces 76 and switching: Layer-2 Switch Capable (L2SC), Time-Division 77 Multiplex (TDM), Lambda Switch Capable (LSC) and Fiber-Switch 78 Capable (FSC). A functional description of the extensions to MPLS 79 signaling needed to support the new classes of interfaces and 80 switching is provided in [RFC3471]. [RFC3473] describes RSVP-TE 81 specific formats and mechanisms needed to support all five classes 82 of interfaces, and CR-LDP extensions can be found in [RFC3472]. 84 This document presents details that are specific to Synchronous 85 Optical Network (SONET)/Synchronous Digital Hierarchy (SDH). Per 86 [RFC3471], SONET/SDH specific parameters are carried in the 87 signaling protocol in traffic parameter specific objects. 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 90 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 91 in this document are to be interpreted as described in [RFC2119]. 93 Moreover, the reader is assumed to be familiar with the 94 terminology in ANSI [T1.105], ITU-T [G.707] as well as [RFC3471], 95 [RFC3472], and [RFC3473]. The following abbreviations are used in 96 this document: 98 DCC: Data Communications Channel. 99 LOVC: Lower Order Virtual Container 100 HOVC: Higher Order Virtual Container 101 MS: Multiplex Section. 102 MSOH: Multiplex Section overhead. 103 POH: Path overhead. 104 RS: Regenerator Section. 105 RSOH: Regenerator section overhead. 107 E.Mannie & D.Papadimitriou (Editors) 2 108 SDH: Synchronous digital hierarchy. 109 SOH: Section overhead. 110 SONET: Synchronous Optical Network. 111 SPE: Synchronous Payload Envelope. 112 STM(-N): Synchronous Transport Module (-N) (SDH). 113 STS(-N): Synchronous Transport Signal-Level N (SONET). 114 VC-n: Virtual Container-n (SDH). 115 VTn: Virtual Tributary-n (SONET). 117 2. SONET and SDH Traffic Parameters 119 This section defines the GMPLS traffic parameters for SONET/SDH. 120 The protocol specific formats, for the SONET/SDH-specific RSVP-TE 121 objects and CR-LDP TLVs are described in sections 2.2 and 2.3 122 respectively. 124 These traffic parameters specify indeed a base set of capabilities 125 for SONET ANSI [T1.105] and SDH ITU-T [G.707] such as 126 concatenation and transparency. Other documents may further 127 enhance this set of capabilities in the future. For instance, 128 signaling for SDH over PDH ITU-T G.832 or sub-STM-0 ITU-T G.708 129 interfaces could be defined. 131 The traffic parameters defined hereafter (see Section 2.1) MUST be 132 used when the label is encoded as SUKLM as defined in this memo 133 (see Section 3). They MUST also be used when requesting one of 134 Section/RS or Line/MS overhead transparent STS-1/STM-0, STS- 135 3*N/STM-N (N=1, 4, 16, 64, 256) signals. 137 The traffic parameters and label encoding defined in [RFC3471], 138 Section 3.2, MUST be used for fully transparent STS-1/STM-0, STS- 139 3*N/STM-N (N=1, 4, 16, 64, 256) signal requests. A fully 140 transparent signal is one for which all overhead is left 141 unmodified by intermediate nodes, i.e., when all defined 142 Transparency (T) bits would be set if the traffic parameters 143 defined in section 2.1 were used. 145 2.1. SONET/SDH Traffic Parameters 147 The traffic parameters for SONET/SDH are organized as follows: 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Signal Type | RCC | NCC | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | NVC | Multiplier (MT) | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Transparency (T) | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Profile (P) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Annex 1 lists examples of SONET and SDH signal coding. 163 E.Mannie & D.Papadimitriou (Editors) 3 164 o) Signal Type (ST): 8 bits 166 This field indicates the type of Elementary Signal that comprises 167 the requested LSP. Several transforms can be applied successively 168 on the Elementary Signal to build the Final Signal being actually 169 requested for the LSP. 171 Each transform application is optional and must be ignored if 172 zero, except the Multiplier (MT) that cannot be zero and is 173 ignored if equal to one. 175 Transforms must be applied strictly in the following order: 177 - First, contiguous concatenation (by using the RCC and NCC 178 fields) can be optionally applied on the Elementary Signal, 179 resulting in a contiguously concatenated signal. 180 - Second, virtual concatenation (by using the NVC field) can be 181 optionally applied on the Elementary Signal resulting in a 182 virtually concatenated signal. 183 - Third, some transparency (by using the Transparency field) can 184 be optionally specified when requesting a frame as signal rather 185 than an SPE or VC based signal. 186 - Fourth, a multiplication (by using the Multiplier field) can be 187 optionally applied either directly on the Elementary Signal, or on 188 the contiguously concatenated signal obtained from the first 189 phase, or on the virtually concatenated signal obtained from the 190 second phase, or on these signals combined with some transparency. 192 Permitted Signal Type values for SONET/SDH are: 194 Value Type (Elementary Signal) 195 ----- ------------------------ 196 1 VT1.5 SPE / VC-11 197 2 VT2 SPE / VC-12 198 3 VT3 SPE 199 4 VT6 SPE / VC-2 200 5 STS-1 SPE / VC-3 201 6 STS-3c SPE / VC-4 202 7 STS-1 / STM-0 (only when requesting transparency) 203 8 STS-3 / STM-1 (only when requesting transparency) 204 9 STS-12 / STM-4 (only when requesting transparency) 205 10 STS-48 / STM-16 (only when requesting transparency) 206 11 STS-192 / STM-64 (only when requesting transparency) 207 12 STS-768 / STM-256 (only when requesting transparency) 209 A dedicated signal type is assigned to a SONET STS-3c SPE instead of 210 coding it as a contiguous concatenation of three STS-1 SPEs. This is 211 done in order to provide easy interworking between SONET and SDH 212 signaling. 214 Appendix 1 adds one signal type (optional) to the above values. 216 E.Mannie & D.Papadimitriou (Editors) 4 217 o) Requested Contiguous Concatenation (RCC): 8 bits 219 This field is used to request the optional SONET/SDH contiguous 220 concatenation of the Elementary Signal. 222 This field is a vector of flags. Each flag indicates the support 223 of a particular type of contiguous concatenation. Several flags 224 can be set at the same time to indicate a choice. 226 These flags allow an upstream node to indicate to a downstream 227 node the different types of contiguous concatenation that it 228 supports. However, the downstream node decides which one to use 229 according to its own rules. 231 A downstream node receiving simultaneously more than one flag 232 chooses a particular type of contiguous concatenation, if any 233 supported, and based on criteria that are out of this document 234 scope. A downstream node that doesn't support any of the 235 concatenation types indicated by the field must refuse the LSP 236 request. In particular, it must refuse the LSP request if it 237 doesn't support contiguous concatenation at all. 239 When several flags have been set, the upstream node retrieves the 240 (single) type of contiguous concatenation the downstream node has 241 selected by looking at the position indicated by the first label 242 and the number of label(s) as returned by the downstream node (see 243 also Section 3). 245 The entire field is set to zero to indicate that no contiguous 246 concatenation is requested at all (default value). A non-zero 247 field indicates that some contiguous concatenation is requested. 249 The following flag is defined: 251 Flag 1 (bit 1): Standard contiguous concatenation. 253 Flag 1 indicates that the standard SONET/SDH contiguous 254 concatenation as defined in [T1.105]/[G.707] is supported. Note 255 that bit 1 is the low order bit. Other flags are reserved for 256 extensions, if not used they must be set to zero when sent, and 257 should be ignored when received. 259 See note 1 hereafter in the section on the NCC about the SONET 260 contiguous concatenation of STS-1 SPEs when the number of 261 components is a multiple of three. 263 o) Number of Contiguous Components (NCC): 16 bits 265 This field indicates the number of identical SONET SPEs/SDH VCs 266 (i.e., Elementary Signal) that are requested to be concatenated, 267 as specified in the RCC field. 269 Note 1: when requesting a SONET STS-Nc SPE with N=3*X, the 271 E.Mannie & D.Papadimitriou (Editors) 5 272 Elementary Signal to use must always be an STS-3c_SPE signal type 273 and the value of NCC must always be equal to X. This allows also 274 facilitating the interworking between SONET and SDH. In 275 particular, it means that the contiguous concatenation of three 276 STS-1 SPEs can not be requested because according to this 277 specification, this type of signal must be coded using the STS-3c 278 SPE signal type. 280 Note 2: when requesting a transparent STS-N/STM-N signal limited 281 to a single contiguously concatenated STS-Nc_SPE/VC-4-Nc, the 282 signal type must be STS-N/STM-N, RCC with flag 1 and NCC set to 1. 284 The NCC value must be consistent with the type of contiguous 285 concatenation being requested in the RCC field. In particular, 286 this field is irrelevant if no contiguous concatenation is 287 requested (RCC = 0), in that case it must be set to zero when 288 sent, and should be ignored when received. A RCC value different 289 from 0 implies a number of contiguous components greater than or 290 equal to 1. 292 Note 3: Following these rules, when requesting a VC-4 signal, the 293 RCC and the NCC values SHOULD be set to 0 whereas for an STS-3c 294 SPE signal, the RCC and the NCC values SHOULD be set 1. However, 295 if local conditions allow and since the setting of the RCC and NCC 296 values is locally driven, the requesting upstream node MAY set the 297 RCC and NCC values to either SDH or SONET settings without 298 impacting the function. Moreover, the downstream node SHOULD 299 accept the requested values if local conditions allow. If these 300 values cannot be supported, the receiver downstream node SHOULD 301 generate a PathErr/NOTIFICATION message (see Section 2.2/2.3, 302 respectively). 304 o) Number of Virtual Components (NVC): 16 bits 306 This field indicates the number of signals that are requested to 307 be virtually concatenated. These signals are all of the same type 308 by definition. They are Elementary Signal SPEs/VCs for which 309 signal types are defined in this document, i.e., VT1.5_SPE/VC-11, 310 VT2_SPE/VC-12, VT3_SPE, VT6_SPE/VC-2, STS-1_SPE/VC-3 or STS- 311 3c_SPE/VC-4. 313 This field is set to 0 (default value) to indicate that no virtual 314 concatenation is requested. 316 o) Multiplier (MT): 16 bits 318 This field indicates the number of identical signals that are 319 requested for the LSP, i.e., that form the Final Signal. These 320 signals can be either identical Elementary Signals, or identical 321 contiguously concatenated signals, or identical virtually 322 concatenated signals. Note that all these signals belong thus to 323 the same LSP. 325 E.Mannie & D.Papadimitriou (Editors) 6 326 The distinction between the components of multiple virtually 327 concatenated signals is done via the order of the labels that are 328 specified in the signaling. The first set of labels must describe 329 the first component (set of individual signals belonging to the 330 first virtual concatenated signal), the second set must describe 331 the second component (set of individual signals belonging to the 332 second virtual concatenated signal) and so on. 334 This field is set to one (default value) to indicate that exactly 335 one instance of a signal is being requested. Intermediate and 336 egress nodes MUST verify that the node itself and the interfaces 337 on which the LSP will be established can support the requested 338 multiplier value. If the requested values can not be supported, 339 the receiver node MUST generate a PathErr/NOTIFICATION message 340 (see Section 2.2/2.3, respectively). 342 Zero is an invalid value. If received, the node MUST generate a 343 PathErr/NOTIFICATION message (see Section 2.2/2.3, respectively). 345 Note 1: when requesting a transparent STS-N/STM-N signal limited 346 to a single contiguously concatenated STS-Nc-SPE/VC-4-Nc, the 347 multiplier field MUST be equal to 1 (only valid value). 349 o) Transparency (T): 32 bits 351 This field is a vector of flags that indicates the type of 352 transparency being requested. Several flags can be combined to 353 provide different types of transparency. Not all combinations are 354 necessarily valid. The default value for this field is zero, i.e., 355 no transparency requested. 357 Transparency, as defined from the point of view of this signaling 358 specification, is only applicable to the fields in the SONET/SDH 359 frame overheads. In the SONET case, these are the fields in the 360 Section Overhead (SOH), and the Line Overhead (LOH). In the SDH 361 case, these are the fields in the Regenerator Section Overhead 362 (RSOH), the Multiplex Section overhead (MSOH), and the pointer 363 fields between the two. With SONET, the pointer fields are part of 364 the LOH. 366 Note as well that transparency is only applicable when using the 367 following Signal Types: STS-1/STM-0, STS-3/STM-1, STS-12/STM-4, 368 STS-48/STM-16, STS-192/STM-64 and STS-768/STM-256. At least one 369 transparency type must be specified when requesting such a signal 370 type. 372 Transparency indicates precisely which fields in these overheads 373 must be delivered unmodified at the other end of the LSP. An 374 ingress LSR requesting transparency will pass these overhead 375 fields that must be delivered to the egress LSR without any 376 change. From the ingress and egress LSRs point of views, these 377 fields must be seen as unmodified. 379 E.Mannie & D.Papadimitriou (Editors) 7 380 Transparency is not applied at the interfaces with the initiating 381 and terminating LSRs, but is only applied between intermediate 382 LSRs. The transparency field is used to request an LSP that 383 supports the requested transparency type; it may also be used to 384 setup the transparency process to be applied at each intermediate 385 LSR. 387 The different transparency flags are the following: 389 Flag 1 (bit 1): Section/Regenerator Section layer. 390 Flag 2 (bit 2): Line/Multiplex Section layer. 392 Where bit 1 is the low order bit. Other flags are reserved, they 393 should be set to zero when sent, and should be ignored when 394 received. A flag is set to one to indicate that the corresponding 395 transparency is requested. 397 Intermediate and egress nodes MUST verify that the node itself and 398 the interfaces on which the LSP will be established can support 399 the requested transparency. If the requested flags can not be 400 supported, the receiver node MUST generate a PathErr/NOTIFICATION 401 message (see Section 2.2/2.3, respectively). 403 Section/Regenerator Section layer transparency means that the 404 entire frames must be delivered unmodified. This implies that 405 pointers cannot be adjusted. When using Section/Regenerator 406 Section layer transparency all other flags MUST be ignored. 408 Line/Multiplex Section layer transparency means that the LOH/MSOH 409 must be delivered unmodified. This implies that pointers cannot be 410 adjusted. 412 o) Profile (P): 32 bits 414 This field is intended to indicate particular capabilities that 415 must be supported for the LSP, for example monitoring 416 capabilities. 418 No standard profile is currently defined and this field SHOULD be 419 set to zero when transmitted and SHOULD be ignored when received. 421 In the future TLV based extensions may be created. 423 2.2. RSVP-TE Details 425 For RSVP-TE, the SONET/SDH traffic parameters are carried in the 426 SONET/SDH SENDER_TSPEC and FLOWSPEC objects. The same format is 427 used both for SENDER_TSPEC object and FLOWSPEC objects. The 428 content of the objects is defined above in Section 2.1. The 429 objects have the following class and type for SONET ANSI T1.105 430 and SDH ITU-T G.707: 432 SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4 433 SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4 435 E.Mannie & D.Papadimitriou (Editors) 8 436 There is no Adspec associated with the SONET/SDH SENDER_TSPEC. 437 Either the Adspec is omitted or an int-serv Adspec with the 438 Default General Characterization Parameters and Guaranteed Service 439 fragment is used, see [RFC2210]. 441 For a particular sender in a session the contents of the FLOWSPEC 442 object received in a Resv message SHOULD be identical to the 443 contents of the SENDER_TSPEC object received in the corresponding 444 Path message. If the objects do not match, a ResvErr message with 445 a "Traffic Control Error/Bad Flowspec value" error SHOULD be 446 generated. 448 Intermediate and egress nodes MUST verify that the node itself and 449 the interfaces on which the LSP will be established can support 450 the requested Signal Type, RCC, NCC, NVC and Multiplier (as 451 defined in Section 2.1). If the requested value(s) can not be 452 supported, the receiver node MUST generate a PathErr message with 453 a "Traffic Control Error/ Service unsupported" indication (see 454 [RFC2205]). 456 In addition, if the MT field is received with a zero value, the 457 node MUST generate a PathErr message with a "Traffic Control 458 Error/Bad Tspec value" indication (see [RFC2205]). 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 PathErr message with a "Traffic Control Error/Service 465 unsupported" indication (see [RFC2205]). 467 2.3. CR-LDP Details 469 For CR-LDP, the SONET/SDH traffic parameters are carried in the 470 SONET/SDH Traffic Parameters TLV. The content of the TLV is 471 defined above in Section 2.1. The header of the TLV has the 472 following format: 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 |U|F| Type | Length | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 The type field for the SONET/SDH Traffic Parameters TLV is: 481 0x0838. 483 Intermediate and egress nodes MUST verify that the node itself and 484 the interfaces on which the LSP will be established can support 485 the requested Signal Type, RCC, NCC, NVC and Multiplier (as 486 defined in Section 2.1). If the requested value(s) can not be 487 supported, the receiver node MUST generate a NOTIFICATION message 488 with a "Resource Unavailable" status code (see [RFC3212]). 490 E.Mannie & D.Papadimitriou (Editors) 9 491 In addition, if the MT field is received with a zero value, the 492 node MUST generate a NOTIFICATION message with a "Resource 493 Unavailable" status code (see [RFC3212]). 495 Intermediate nodes MUST also verify that the node itself and the 496 interfaces on which the LSP will be established can support the 497 requested Transparency (as defined in Section 2.1). If the 498 requested value(s) can not be supported, the receiver node MUST 499 generate a NOTIFICATION message with a "Resource Unavailable" 500 status code (see [RFC3212]). 502 3. SONET and SDH Labels 504 SONET and SDH each define a multiplexing structure. Both 505 structures are trees whose roots are respectively an STS-N or an 506 STM-N; and whose leaves are the signals that can be transported 507 via the time-slots and switched between time-slots within an 508 ingress port and time-slots within an egress port, i.e., a VTx 509 SPE, an STS-x SPE or a VC-x. A SONET/SDH label will identify the 510 exact position (i.e., first time-slot) of a particular VTx SPE, 511 STS-x SPE or VC-x signal in a multiplexing structure. SONET and 512 SDH labels are carried in the Generalized Label per [RFC3473] and 513 [RFC3472]. 515 Note that by time-slots we mean the time-slots as they appear 516 logically and sequentially in the multiplex, not as they appear 517 after any possible interleaving. 519 These multiplexing structures will be used as naming trees to 520 create unique multiplex entry names or labels. The same format of 521 label is used for SONET and SDH. As explained in [RFC3471], a 522 label does not identify the "class" to which the label belongs. 523 This is implicitly determined by the link on which the label is 524 used. 526 In case of signal concatenation or multiplication, a list of 527 labels can appear in the Label field of a Generalized Label. 529 In case of contiguous concatenation, only one label appears in the 530 Label field. This unique label is encoded as a single 32 bit label 531 value (as defined in this Section) of the Generalized Label object 532 (Class-Num = 16, C-Type = 2)/TLV (0x0825). This label identifies 533 the lowest time-slot occupied by the contiguously concatenated 534 signal. By lowest time-slot we mean the one having the lowest 535 label (value) when compared as integer values, i.e., the time-slot 536 occupied by the first component signal of the concatenated signal 537 encountered when descending the tree. 539 In case of virtual concatenation, the explicit ordered list of all 540 labels in the concatenation is given. This ordered list of labels 541 is encoded as a sequence of 32 bit label values (as defined in 542 this Section) of the Generalized Label object (Class-Num = 16, C- 543 Type = 2)/TLV (0x0825). Each label indicates the first time-slot 545 E.Mannie & D.Papadimitriou (Editors) 10 546 occupied by a component of the virtually concatenated signal. The 547 order of the labels must reflect the order of the payloads to 548 concatenate (not the physical order of time-slots). The above 549 representation limits virtual concatenation to remain within a 550 single (component) link; it imposes as such a restriction compared 551 to the ANSI [T1.105]/ ITU-T [G.707] recommendations. The standard 552 definition for virtual concatenation allows each virtual 553 concatenation components to travel over diverse paths. Within 554 GMPLS, virtual concatenation components must travel over the same 555 (component) link if they are part of the same LSP. This is due to 556 the way that labels are bound to a (component) link. Note however, 557 that the routing of components on different paths is indeed 558 equivalent to establishing different LSPs, each one having its own 559 route. Several LSPs can be initiated and terminated between the 560 same nodes and their corresponding components can then be 561 associated together (i.e., virtually concatenated). 563 In case of multiplication (i.e., using the multiplier transform), 564 the explicit ordered list of all labels that take part in the 565 Final Signal is given. This ordered list of labels is encoded as a 566 sequence of 32 bit label values (as defined in this Section) of 567 the Generalized Label object (Class-Num = 16, C-Type = 2)/TLV 568 (0x0825). In case of multiplication of virtually concatenated 569 signals, the explicit ordered list of set of labels that take part 570 in the Final Signal is given. The first set of labels indicates 571 the time-slots occupied by the first virtually concatenated 572 signal, the second set of labels indicates the time-slots occupied 573 by the second virtually concatenated signal, and so on. The above 574 representation limits multiplication to remain within a single 575 (component) link. 577 The format of the label for SONET and/or SDH TDM-LSR link is: 579 0 1 2 3 580 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 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | S | U | K | L | M | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 This is an extension of the numbering scheme defined in [G.707] 586 sections 7.3.7 to 7.3.13, i.e., the (K, L, M) numbering. Note 587 that the higher order numbering scheme defined in [G.707] sections 588 7.3.1 to 7.3.6 is not used here. 590 Each letter indicates a possible branch number starting at the 591 parent node in the multiplex structure. Branches are considered as 592 numbered in increasing order, starting from the top of the 593 multiplexing structure. The numbering starts at 1, zero is used to 594 indicate a non-significant or ignored field. 596 When a field is not significant or ignored in a particular context 597 it MUST be set to zero when transmitted, and MUST be ignored when 598 received. 600 E.Mannie & D.Papadimitriou (Editors) 11 601 When a hierarchy of SONET/SDH LSPs is used, a higher order LSP 602 with a given bandwidth can be used to carry lower order LSPs. 603 Remember here that a higher order LSP is established through a 604 SONET/SDH higher order path layer network and a lower order LSP, 605 through a SONET/SDH lower order path layer network (see also ITU-T 606 G.803, Section 3 for the corresponding definitions). In this 607 context, the higher order SONET/SDH LSP behaves as a "virtual 608 link" with a given bandwidth (e.g., VC-3), it may also be used as 609 a Forwarding Adjacency. A lower order SONET/SDH LSP can be 610 established through that higher order LSP. Since a label is local 611 to a (virtual) link, the highest part of that label (i.e., the S, 612 U and K fields) is non-significant and is set to zero, i.e., the 613 label is "0,0,0,L,M". Similarly, if the structure of the lower 614 order LSP is unknown or not relevant, the lowest part of that 615 label (i.e., the L and M fields) is non-significant and is set to 616 zero, i.e., the label is "S,U,K,0,0". 618 For instance, a VC-3 LSP can be used to carry lower order LSPs. 619 In that case the labels allocated between the two ends of the VC-3 620 LSP for the lower order LSPs will have S, U and K set to zero, 621 i.e., non-significant, while L and M will be used to indicate the 622 signal allocated in that VC-3. 624 In case of tunneling such as VC-4 containing VC-3 containing 625 VC-12/VC-11 where the SUKLM structure is not adequate to represent 626 the full signal structure, a hierarchical approach must be used, 627 i.e., per layer network signaling. 629 The possible values of S, U, K, L and M are defined as follows: 631 1. S=1->N is the index of a particular STS-3/AUG-1 inside an 632 STS-N/STM-N multiplex. S is only significant for SONET STS-N 633 (N>1) and SDH STM-N (N>0). S must be 0 and ignored for STS-1 634 and STM-0. 636 2. U=1->3 is the index of a particular STS-1_SPE/VC-3 within an 637 STS-3/AUG-1. U is only significant for SONET STS-N (N>1) and 638 SDH STM-N (N>0). U must be 0 and ignored for STS-1 and STM-0. 640 3. K=1->3 is the index of a particular TUG-3 within a VC-4. K is 641 only significant for an SDH VC-4 structured in TUG-3s. K must 642 be 0 and ignored in all other cases. 644 4. L=1->7 is the index of a particular VT_Group/TUG-2 within an 645 STS-1_SPE/TUG-3 or VC-3. L must be 0 and ignored in all other 646 cases. 648 5. M is the index of a particular VT1.5_SPE/VC-11, VT2_SPE/VC-12 649 or VT3_SPE within a VT_Group/TUG-2. M=1->2 indicates a specific 650 VT3 SPE inside the corresponding VT Group, these values MUST 651 NOT be used for SDH since there is no equivalent of VT3 with 652 SDH. M=3->5 indicates a specific VT2_SPE/VC-12 inside the 653 corresponding VT_Group/TUG-2. M=6->9 indicates a specific 654 VT1.5_SPE/VC-11 inside the corresponding VT_Group/TUG-2. 656 E.Mannie & D.Papadimitriou (Editors) 12 657 Note that a label always has to be interpreted according the 658 SONET/SDH traffic parameters, i.e., a label by itself does not 659 allow knowing which signal is being requested (a label is context 660 sensitive). 662 The label format defined in this section, referred to as SUKLM, 663 MUST be used for any SONET/SDH signal requests that are not 664 transparent i.e., when all Transparency (T) bits defined in 665 section 2.1 are set to zero. Any transparent STS-1/STM-0/STS- 666 3*N/STM-N (N=1, 4, 16, 64, 256) signal request MUST use a label 667 format as defined in [RFC3471]. 669 The S encoding is summarized in the following table: 671 S SDH SONET 672 ------------------------------------------------ 673 0 other other 674 1 1st AUG-1 1st STS-3 675 2 2nd AUG-1 2nd STS-3 676 3 3rd AUG-1 3rd STS-3 677 4 4rd AUG-1 4rd STS-3 678 : : : 679 N Nth AUG-1 Nth STS-3 681 The U encoding is summarized in the following table: 683 U SDH AUG-1 SONET STS-3 684 ------------------------------------------------- 685 0 other other 686 1 1st VC-3 1st STS-1 SPE 687 2 2nd VC-3 2nd STS-1 SPE 688 3 3rd VC-3 3rd STS-1 SPE 690 The K encoding is summarized in the following table: 692 K SDH VC-4 693 --------------- 694 0 other 695 1 1st TUG-3 696 2 2nd TUG-3 697 3 3rd TUG-3 699 The L encoding is summarized in the following table: 701 L SDH TUG-3 SDH VC-3 SONET STS-1 SPE 702 ------------------------------------------------- 703 0 other other other 704 1 1st TUG-2 1st TUG-2 1st VTG 705 2 2nd TUG-2 2nd TUG-2 2nd VTG 706 3 3rd TUG-2 3rd TUG-2 3rd VTG 707 4 4th TUG-2 4th TUG-2 4th VTG 708 5 5th TUG-2 5th TUG-2 5th VTG 709 6 6th TUG-2 6th TUG-2 6th VTG 711 E.Mannie & D.Papadimitriou (Editors) 13 712 7 7th TUG-2 7th TUG-2 7th VTG 714 The M encoding is summarized in the following table: 716 M SDH TUG-2 SONET VTG 717 ------------------------------------------------- 718 0 other other 719 1 - 1st VT3 SPE 720 2 - 2nd VT3 SPE 721 3 1st VC-12 1st VT2 SPE 722 4 2nd VC-12 2nd VT2 SPE 723 5 3rd VC-12 3rd VT2 SPE 724 6 1st VC-11 1st VT1.5 SPE 725 7 2nd VC-11 2nd VT1.5 SPE 726 8 3rd VC-11 3rd VT1.5 SPE 727 9 4th VC-11 4th VT1.5 SPE 729 Examples of labels: 731 Example 1: the label for the STS-3c_SPE/VC-4 in the Sth STS-3/AUG- 732 1 is: S>0, U=0, K=0, L=0, M=0. 734 Example 2: the label for the VC-3 within the Kth-1 TUG-3 within 735 the VC-4 in the Sth AUG-1 is: S>0, U=0, K>0, L=0, M=0. 737 Example 3: the label for the Uth-1 STS-1_SPE/VC-3 within the Sth 738 STS-3/AUG-1 is: S>0, U>0, K=0, L=0, M=0. 740 Example 4: the label for the VT6/VC-2 in the Lth-1 VT Group/TUG-2 741 in the Uth-1 STS-1_SPE/VC-3 within the Sth STS-3/AUG-1 742 is: S>0, U>0, K=0, L>0, M=0. 744 Example 5: the label for the 3rd VT1.5_SPE/VC-11 in the Lth-1 VT 745 Group/TUG-2 within the Uth-1 STS-1_SPE/VC-3 within the 746 Sth STS-3/AUG-1 is: S>0, U>0, K=0, L>0, M=8. 748 Example 6: the label for the STS-12c SPE/VC-4-4c which uses the 749 9th STS-3/AUG-1 as its first timeslot is: S=9, U=0, 750 K=0, L=0, M=0. 752 In case of contiguous concatenation, the label that is used is the 753 lowest label (value) of the contiguously concatenated signal as 754 explained before. The higher part of the label indicates where the 755 signal starts and the lowest part is not significant. 757 In case of STM-0/STS-1, the values of S, U and K must be equal to 758 zero according to the field coding rules. For instance, when 759 requesting a VC-3 in an STM-0 the label is S=0, U=0, K=0, L=0, 760 M=0. When requesting a VC-11 in a VC-3 in an STM-0 the label is 761 S=0, U=0, K=0, L>0, M=6..9. 763 Note: when a Section/RS or Line/MS transparent STS-1/STM-0/STS- 764 3*N/STM-N (N=1, 4, 16, 64, 256) signal is requested, the SUKLM 766 E.Mannie & D.Papadimitriou (Editors) 14 767 label format and encoding is not applicable and the label encoding 768 MUST follow the rules defined in [RFC3471] Section 3.2. 770 4. Acknowledgments 772 Valuable comments and input were received from the CCAMP mailing 773 list where outstanding discussions took place. 775 The authors would like to thank Richard Rabbat for its valuable 776 input that lead to this revision. 778 5. Security Considerations 780 This document introduces no new security considerations to either 781 [RFC3473] or [RFC3472]. GMPLS security is described in section 11 782 of [RFC3471] and refers to [RFC3209] for RSVP-TE and to [RFC3212] 783 for CR-LDP. 785 6. IANA Considerations 787 Three values have been defined by IANA for this document. 789 Two RSVP C-Types in registry: 790 http://www.iana.org/assignments/rsvp-parameters 792 - A SONET/SDH SENDER_TSPEC object: Class = 12, C-Type = 4 (see 793 Section 2.2). 795 - A SONET/SDH FLOWSPEC object: Class = 9, C-Type = 4 (see 796 Section 2.2). 798 One LDP TLV Type in registry: 799 http://www.iana.org/assignments/ldp-namespaces 801 - A type field for the SONET/SDH Traffic Parameters TLV (see 802 Section 2.3). 804 7. References 806 7.1 Normative References 808 [G.707] ITU-T Recommendation G.707, "Network Node Interface for 809 the Synchronous Digital Hierarchy", October 2000. 811 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 812 Requirement Levels", BCP 14, RFC 2119, March 1997. 814 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 815 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 816 1 Functional Specification", RFC 2205, September 1997. 818 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 819 Services", RFC 2210, September 1997. 821 E.Mannie & D.Papadimitriou (Editors) 15 823 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 824 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 825 Tunnels", RFC 3209, December 2001. 827 [RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., 828 Wu, L., Doolan, P., Worster, T., Feldman, N., 829 Fredette, A., Girish, M., Gray, E., Heinanen, J., 830 Kilty, T., and A. Malis, "Constraint-Based LSP Setup 831 using LDP", RFC 3212, January 2002. 833 [RFC3471] Berger, L., "Generalized Multi-Protocol Label 834 Switching (MPLS) Signaling Functional Description", 835 RFC 3471, January 2003. 837 [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi- 838 Protocol Label Switching (MPLS) Signaling - 839 Constraint-based Routed Label Distribution Protocol 840 (CR-LDP) Extensions", RFC 3472, January 2003. 842 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 843 Switching (MPLS) Signaling - Resource ReserVation 844 Protocol Traffic Engineering (RSVP-TE) Extensions", 845 RFC 3473, January 2003. 847 [RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label 848 Switching (GMPLS) Architecture", RFC 3945, October 849 2004. 851 [T1.105] "Synchronous Optical Network (SONET): Basic 852 Description Including Multiplex Structure, Rates, and 853 Formats", ANSI T1.105, October 2000. 855 E.Mannie & D.Papadimitriou (Editors) 16 856 Appendix 1 - Signal Type Values Extension for VC-3 858 This appendix defines the following optional additional Signal 859 Type value for the Signal Type field of section 2.1: 861 Value Type 862 ----- --------------------- 863 20 "VC-3 via AU-3 at the end" 865 According to the ITU-T [G.707] recommendation a VC-3 in the TU- 866 3/TUG-3/VC-4/AU-4 branch of the SDH multiplex cannot be structured 867 in TUG-2s, however a VC-3 in the AU-3 branch can be. In addition, 868 a VC-3 could be switched between the two branches if required. 870 A VC-3 circuit could be terminated on an ingress interface of an 871 LSR (e.g. forming a VC-3 forwarding adjacency). This LSR could 872 then want to demultiplex this VC-3 and switch internal low order 873 LSPs. For implementation reasons, this could be only possible if 874 the LSR receives the VC-3 in the AU-3 branch. E.g. for an LSR not 875 able to switch internally from a TU-3 branch to an AU-3 branch on 876 its incoming interface before demultiplexing and then switching 877 the content with its switch fabric. 879 In that case it is useful to indicate that the VC-3 LSP must be 880 terminated at the end in the AU-3 branch instead of the TU-3 881 branch. 883 This is achieved by using the "VC-3 via AU-3 at the end" signal 884 type. This information can be used, for instance, by the 885 penultimate LSR to switch an incoming VC-3 received in any branch 886 to the AU-3 branch on the outgoing interface to the destination 887 LSR. 889 The "VC-3 via AU-3 at the end" signal type does not imply that the 890 VC-3 must be switched via the AU-3 branch at some other places in 891 the network. The VC-3 signal type just indicates that a VC-3 in 892 any branch is suitable. 894 E.Mannie & D.Papadimitriou (Editors) 17 895 Annex 1 - Examples 897 This annex defines examples of SONET and SDH signal coding. Their 898 objective is to help the reader to understand how works the traffic 899 parameter coding and not to give examples of typical SONET or SDH 900 signals. 902 As stated above, signal types are Elementary Signals to which 903 successive concatenation, multiplication and transparency 904 transforms can be applied to obtain Final Signals. 906 1. A VC-4 signal is formed by the application of RCC with value 907 0, NCC with value 0, NVC with value 0, MT with value 1 and T 908 with value 0 to a VC-4 Elementary Signal. 910 2. A VC-4-7v signal is formed by the application of RCC with value 911 0, NCC with value 0, NVC with value 7 (virtual concatenation of 912 7 components), MT with value 1 and T with value 0 to a VC-4 913 Elementary Signal. 915 3. A VC-4-16c signal is formed by the application of RCC with 916 value 1 (standard contiguous concatenation), NCC with value 16, 917 NVC with value 0, MT with value 1 and T with value 0 to a VC-4 918 Elementary Signal. 920 4. An STM-16 signal with Multiplex Section layer transparency is 921 formed by the application of RCC with value 0, NCC with value 922 0, NVC with value 0, MT with value 1 and T with flag 2 to an 923 STM-16 Elementary Signal. 925 5. An STM-4 signal with Multiplex Section layer transparency is 926 formed by the application of RCC with value 0, NCC with value 927 0, NVC with value 0, MT with value 1 and T with flag 2 applied 928 to an STM-4 Elementary Signal. 930 6. An STM-256 signal with Multiplex Section layer transparency is 931 formed by the application of RCC with value 0, NCC with value 932 0, NVC with value 0, MT with value 1 and T with flag 2 applied 933 to an STM-256 Elementary Signal. 935 7. An STS-1 SPE signal is formed by the application of RCC with 936 value 0, NCC with value 0, NVC with value 0, MT with value 1 937 and T with value 0 to an STS-1 SPE Elementary Signal. 939 8. An STS-3c SPE signal is formed by the application of RCC with 940 value 1 (standard contiguous concatenation), NCC with value 1, 941 NVC with value 0, MT with value 1 and T with value 0 to an STS- 942 3c SPE Elementary Signal. 944 9. An STS-48c SPE signal is formed by the application of RCC with 945 value 1 (standard contiguous concatenation), NCC with value 16, 946 NVC with value 0, MT with value 1 and T with value 0 to an STS- 947 3c SPE Elementary Signal. 949 E.Mannie & D.Papadimitriou (Editors) 18 950 10.An STS-1-3v SPE signal is formed by the application of RCC 951 with value 0, NVC with value 3 (virtual concatenation of 3 952 components), MT with value 1 and T with value 0 to an STS-1 SPE 953 Elementary Signal. 955 11.An STS-3c-9v SPE signal is formed by the application of RCC 956 with value 1, NCC with value 1, NVC with value 9 (virtual 957 concatenation of 9 STS-3c), MT with value 1 and T with value 0 958 to an STS-3c SPE Elementary Signal. 960 12.An STS-12 signal with Section layer (full) transparency is 961 formed by the application of RCC with value 0, NCC with value 962 0, NVC with value 0, MT with value 1 and T with flag 1 to an 963 STS-12 Elementary Signal. 965 13.A 3 x STS-768c SPE signal is formed by the application of RCC 966 with value 1, NCC with value 256, NVC with value 0, MT with 967 value 3, and T with value 0 to an STS-3c SPE Elementary Signal. 969 14. 970 A 5 x VC-4-13v composed signal is formed by the application of 971 RCC with value 0, NVC with value 13, MT with value 5 and T with 972 value 0 to a VC-4 Elementary Signal. 974 The encoding of these examples is summarized in the following 975 table: 977 Signal ST RCC NCC NVC MT T 978 -------------------------------------------------------- 979 VC-4 6 0 0 0 1 0 980 VC-4-7v 6 0 0 7 1 0 981 VC-4-16c 6 1 16 0 1 0 982 STM-16 MS transparent 10 0 0 0 1 2 983 STM-4 MS transparent 9 0 0 0 1 2 984 STM-256 MS transparent 12 0 0 0 1 2 985 STS-1 SPE 5 0 0 0 1 0 986 STS-3c SPE 6 1 1 0 1 0 987 STS-48c SPE 6 1 16 0 1 0 988 STS-1-3v SPE 5 0 0 3 1 0 989 STS-3c-9v SPE 6 1 1 9 1 0 990 STS-12 Section transparent 9 0 0 0 1 1 991 3 x STS-768c SPE 6 1 256 0 3 0 992 5 x VC-4-13v 6 0 0 13 5 0 994 Contributors 996 Contributors are listed by alphabetical order: 998 Stefan Ansorge (Alcatel) 999 Lorenzstrasse 10 1000 70435 Stuttgart, Germany 1001 EMail: stefan.ansorge@alcatel.de 1003 Peter Ashwood-Smith (Nortel) 1004 PO. Box 3511 Station C, 1006 E.Mannie & D.Papadimitriou (Editors) 19 1007 Ottawa, ON K1Y 4H7, Canada 1008 EMail:petera@nortelnetworks.com 1010 Ayan Banerjee (Calient) 1011 5853 Rue Ferrari 1012 San Jose, CA 95138, USA 1013 EMail: abanerjee@calient.net 1015 Lou Berger (Movaz) 1016 7926 Jones Branch Drive 1017 McLean, VA 22102, USA 1018 EMail: lberger@movaz.com 1020 Greg Bernstein (Ciena) 1021 10480 Ridgeview Court 1022 Cupertino, CA 94014, USA 1023 EMail: greg@ciena.com 1025 Angela Chiu (Celion) 1026 One Sheila Drive, Suite 2 1027 Tinton Falls, NJ 07724-2658 1028 EMail: angela.chiu@celion.com 1030 John Drake (Calient) 1031 5853 Rue Ferrari 1032 San Jose, CA 95138, USA 1033 EMail: jdrake@calient.net 1035 Yanhe Fan (Axiowave) 1036 100 Nickerson Road 1037 Marlborough, MA 01752, USA 1038 EMail: yfan@axiowave.com 1040 Michele Fontana (Alcatel) 1041 Via Trento 30, 1042 I-20059 Vimercate, Italy 1043 EMail: michele.fontana@alcatel.it 1045 Gert Grammel (Alcatel) 1046 Lorenzstrasse, 10 1047 70435 Stuttgart, Germany 1048 EMail: gert.grammel@alcatel.de 1050 Juergen Heiles (Siemens) 1051 Hofmannstr. 51 1052 D-81379 Munich, Germany 1053 EMail: juergen.heiles@siemens.com 1055 Suresh Katukam (Cisco) 1056 1450 N. McDowell Blvd, 1057 Petaluma, CA 94954-6515, USA 1058 EMail: suresh.katukam@cisco.com 1060 Kireeti Kompella (Juniper) 1062 E.Mannie & D.Papadimitriou (Editors) 20 1063 1194 N. Mathilda Ave. 1064 Sunnyvale, CA 94089, USA 1065 EMail: kireeti@juniper.net 1067 Jonathan P. Lang (Calient) 1068 25 Castilian 1069 Goleta, CA 93117, USA 1070 EMail: jplang@calient.net 1072 Fong Liaw (Solas Research) 1073 EMail: fongliaw@yahoo.com 1075 Zhi-Wei Lin (Lucent) 1076 101 Crawfords Corner Rd 1077 Holmdel, NJ 07733-3030, USA 1078 EMail: zwlin@lucent.com 1080 Ben Mack-Crane (Tellabs) 1081 EMail: ben.mack-crane@tellabs.com 1083 Dimitrios Pendarakis (Tellium) 1084 2 Crescent Place, P.O. Box 901 1085 Oceanport, NJ 07757-0901, USA 1086 EMail: dpendarakis@tellium.com 1088 Mike Raftelis (White Rock) 1089 18111 Preston Road 1090 Dallas, TX 75252, USA 1092 Bala Rajagopalan (Tellium) 1093 2 Crescent Place, P.O. Box 901 1094 Oceanport, NJ 07757-0901, USA 1095 EMail: braja@tellium.com 1097 Yakov Rekhter (Juniper) 1098 1194 N. Mathilda Ave. 1099 Sunnyvale, CA 94089, USA 1100 EMail: yakov@juniper.net 1102 Debanjan Saha (Tellium) 1103 2 Crescent Place, P.O. Box 901 1104 Oceanport, NJ 07757-0901, USA 1105 EMail: dsaha@tellium.com 1107 Vishal Sharma (Metanoia) 1108 335 Elan Village Lane 1109 San Jose, CA 95134, USA 1110 EMail: vsharma87@yahoo.com 1112 George Swallow (Cisco) 1113 250 Apollo Drive 1114 Chelmsford, MA 01824, USA 1115 EMail: swallow@cisco.com 1117 E.Mannie & D.Papadimitriou (Editors) 21 1118 Z. Bo Tang (Tellium) 1119 2 Crescent Place, P.O. Box 901 1120 Oceanport, NJ 07757-0901, USA 1121 EMail: btang@tellium.com 1123 Eve Varma (Lucent) 1124 101 Crawfords Corner Rd 1125 Holmdel, NJ 07733-3030, USA 1126 EMail: evarma@lucent.com 1128 Yangguang Xu (Lucent) 1129 21-2A41, 1600 Osgood Street 1130 North Andover, MA 01845, USA 1131 EMail: xuyg@lucent.com 1133 Authors' Addresses 1135 Eric Mannie (Consultant) 1136 Avenue de la Folle Chanson, 2 1137 B-1050 Brussels, Belgium 1138 Phone: +32 2 648-5023 1139 Mobile: +32 (0)495-221775 1141 EMail: eric_mannie@hotmail.com 1143 Dimitri Papadimitriou (Alcatel) 1144 Francis Wellesplein 1, 1145 B-2018 Antwerpen, Belgium 1146 Phone: +32 3 240-8491 1148 EMail: dimitri.papadimitriou@alcatel.be 1150 E.Mannie & D.Papadimitriou (Editors) 22 1151 Full Copyright Statement 1153 Copyright (C) The Internet Society (2005). 1155 This document is subject to the rights, licenses and restrictions 1156 contained in BCP 78, and except as set forth therein, the authors 1157 retain all their rights. 1159 This document and the information contained herein are provided on 1160 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1161 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1162 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1163 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1164 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1165 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1166 PARTICULAR PURPOSE. 1168 Intellectual Property 1170 The IETF takes no position regarding the validity or scope of any 1171 Intellectual Property Rights or other rights that might be claimed 1172 to pertain to the implementation or use of the technology 1173 described in this document or the extent to which any license 1174 under such rights might or might not be available; nor does it 1175 represent that it has made any independent effort to identify any 1176 such rights. Information on the IETF's procedures with respect to 1177 rights in IETF Documents can be found in BCP 78 and BCP 79. 1179 Copies of IPR disclosures made to the IETF Secretariat and any 1180 assurances of licenses to be made available, or the result of an 1181 attempt made to obtain a general license or permission for the use 1182 of such proprietary rights by implementers or users of this 1183 specification can be obtained from the IETF on-line IPR repository 1184 at http://www.ietf.org/ipr. 1186 The IETF invites any interested party to bring to its attention 1187 any copyrights, patents or patent applications, or other 1188 proprietary rights that may cover technology that may be required 1189 to implement this standard. Please address the information to the 1190 IETF at ietf-ipr@ietf.org. 1192 Acknowledgement 1194 Funding for the RFC Editor function is currently provided by the 1195 Internet Society. 1197 E.Mannie & D.Papadimitriou (Editors) 23