idnits 2.17.1 draft-otani-ccamp-gmpls-cspf-constraints-07.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, updated by RFC 4748 on line 708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 618. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'LSP-HIER' is mentioned on line 287, but not defined == Unused Reference: 'RFC2119' is defined on line 630, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Tomohiro Otani (Editor) 3 Intended status: Informational Kenichi Ogaki (Editor) 4 Expires: May 2008 KDDI R&D Labs 5 Daniel King(Editor) 6 Aria Networks 8 November 19 2007 10 Considering Generalized Multiprotocol Label Switching Traffic 11 Engineering Attributes During Path Computation 13 Document: draft-otani-ccamp-gmpls-cspf-constraints-07.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-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). All Rights Reserved. 40 Abstract 42 This document provides guidelines for the consideration of 43 Generalized Multiprotocol Label Switching (GMPLS) Traffic-Engineering 44 (TE) attributes for computation of routes for Label Switched Paths 45 (LSPs) in a GMPLS network. 46 This document summarizes how GMPLS TE attributes on ingress 47 links, transit links, and egress links may be treated as path 48 computation constraints to determine the route of a GMPLS Label 49 Switched Path (LSP). 51 T. Otani et al. Expires May 2008 1 52 November 2007 54 Table of Contents 56 Status of this Memo..................................................1 57 Abstract.............................................................1 58 1. Introduction......................................................3 59 2. Problem Statements................................................3 60 3. Assumed Network Model.............................................4 61 4. Path Computation Considerations...................................6 62 5. Security consideration...........................................13 63 6. Acknowledgements.................................................14 64 7. Intellectual Property Considerations.............................14 65 8. IANA Considerations..............................................15 66 9. References.......................................................15 67 November 2007 69 1. Introduction 71 A network is, in general, controlled and managed taking into account 72 various attributes of the underlying technologies of the physical and 73 logical links and nodes. In a network operated using Generalized 74 Multiprotocol Label Switching (GMPLS) protocols, many of these 75 Traffic Engineering (TE) attributes are advertised using routing 76 protocols [RFC3945], [RFC4202]. 78 To establish a GMPLS Label Switched Path (LSP) it is necessary 79 to compute a route or path for that LSP either hop-by-hop or by the 80 pre-calculation of part or all of the path. In order that the route 81 selected is capable of satisfying the requirements of the user or 82 application that will use the LSP the computation must be constrained 83 by a set of LSP-specific requirements and the TE attributes 84 advertised within the network. Further, considerations of technology 85 and node or link capabilities may also provide restrictions to the 86 feasibility of LSP establishment on certain routes, and this can be 87 deduced from the TE attributes advertised within the network and used 88 by the path computation algorithms to select only viable routes. 90 In a mixed, integrated network (for example, one containing 91 optical switches and packet routers) these constraints may vary and 92 are understood differently for different equipment and different LSPs. 93 This document provides guidelines to facilitate path computation for 94 GMPLS LSPs by summarizing how GMPLS TE attributes on ingress links, 95 transit links, and egress links may be treated as path computation 96 constraints to determine the route of a GMPLS Label Switched Path 97 (LSP). 99 2. Problem Statements 101 A GMPLS network is assumed to be composed of different switching 102 capabilities for nodes and different encoding types for TE links. 103 Such a GMPLS network is usually deployed by adopting multiple vendors 104 and each vendor usually has each constraint for a CSPF path 105 calculation and then a problem appears that a signaling message 106 including a calculated route at an ingress node may be rejected at a 107 transit node and the path creation may fail because of the difference 108 of the constraint for a CSPF path calculation between these nodes. 110 In an example network as shown in Figure 1, when ingress Router1 111 calculates a path to egress Router2 without considering the encoding 112 type for transit TE links and sends path message to PXC1, PXC1 113 returns path error message to Router1 because PXC1 cannot 114 crossconnect from ethernet encoding link to sonet/sdh encoding link. 115 In this case, if ingress Router1 can calculate with the exact match 116 for all the links through the ingress node to the egress node, the 117 path can be established. 119 November 2007 121 Router1--(Ethernet)--PXC1--(SONET/SDH)--PXC2--(Ethernet)--Router2 123 *(): Encoding type 124 Figure 1: example network1 126 On the other hand, when a network includes optical switching nodes 127 such as ROADMs which have a link with the encoding type of lambda 128 between nodes as shown in Figure2 and ingress Router1 calculate with 129 the exact match through all the links, the path calculation will fail. 130 In this environment, even if the encoding type of ingress and egress 131 links is different from transit links, the path should be established. 132 Therefore, constraints for various cases of path calculation must be 133 clearly defined. 135 Router1 Router3 136 \ / 137 \ / 138 (Ethernet) (Ethernet) 139 \ / 140 \ / 141 ROADM1--(Lambda)--ROADM2--(Lambda)--ROADM3 142 / \ 143 / \ 144 (SONET/SDH) (SONET/SDH) 145 / \ 146 / \ 147 Router2 Router4 149 Figure 2: example network2 151 3. Assumed Network Model 153 3.1 GMPLS TE Attributes Consideration for Path Calculation 155 For path computation to establish GMPLS LSPs correctly, various GMPLS 156 attributes [RFC4202], [RFC4203] of links as well as nodes, as 157 indicated below, must be taken into account in a GMPLS network 158 environment in addition to TE attributes of packet based network 159 [RFC3630]. 161 (1) Encoding-type: Synchronous Optical Network 162 (SONET)/Synchronous Digital Hierarchy (SDH), Lambda, Ethernet, 163 etc. 164 (2) Switching capability: Time Division Multiplex (TDM), Lambda, 165 Fiber, etc. 166 (3) Bandwidth: OC-192, OC-48, GbE, 10GbE, etc. 168 November 2007 170 These logical attributes have a very tight relationship with 171 underlying physical technologies such as SONET/SDH, Optical Transport 172 Network (OTN) or Ethernet in terms of links, and all-optical switches, 173 SONET/SDH-basis digital cross connect or electrical-basis optical 174 switches in terms of nodes. Therefore, the GMPLS LSPs must satisfy 175 logical constrains as well as corresponding physical constraints. 176 These constraints are sometimes differently understood among 177 different layers, and a logically computed GMPLS LSP may violate the 178 physical constraints, therefore, a consistent guideline to solve this 179 issue should be formulated. 181 3.2 Considered Network Model 183 Figure 3 depicts a typical GMPLS network, consisting of an ingress 184 link, a transit link as well as an egress link, to investigate a 185 consistent guideline for GMPLS path computation. Each link at each 186 interface has its own switching capability, encoding type and 187 bandwidth. 188 The consideration here is based on a single domain GMPLS network, but 189 the analysis maybe applicable to an inter-domain GMPLS networks. 191 Ingress Transit Egress 192 +-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+ 193 |Node1|------------>|Node2|------------>|Node3|------------>|Node4| 194 | |<------------| |<------------| |<------------| | 195 +-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+ 197 Figure 3: GMPLS Network Model 199 For the simplicity of the analysis in path consideration, the below 200 basic assumptions are made when the LSP is created. 202 (1) Switching capabilities (SC) of outgoing links from the 203 ingress and egress nodes (link1-2 and link4-3 in Figure 1) 204 must be consistent with each other. 205 (2) SC of all transit links including incoming links to the 206 ingress and egress nodes (link2-1 and link3-4) should be 207 consistent with switching type of a LSP to be created. 208 (3) Encoding-types of all transit links should be consistent 209 with encoding type of a LSP to be created. 211 A GMPLS network maybe a multi-layer network, which is composed of 212 multiple nodes with different switching capabilities and interface 213 encoding types. Therefore, a hierarchical structure may be considered 214 in path computation. In such a case, the combination between the 215 switching type and encoding type of a desired LSP, and those of all 216 transit links described as the table in following section may be 217 November 2007 219 acceptable. One of advertised multiple interface switching capability 220 descriptors for the same link [RFC4202] should be also appropriately 221 chosen as the attribute for the link. 223 Bandwidth of each TE link is maximum LSP bandwidth in interface 224 switching capability descriptor at the priority for a desired LSP 225 [RFC4203], and encoding-types of incoming and outgoing links on the 226 same interface (for example, link1-2 and link2-1) should be 227 consistent with each other. 229 In case that the network is comprised of numbered links and 230 unnumbered links [RFC3477], an ingress node, who is able to support 231 numbered links and unnumbered links may choose both links being part 232 of the same desired LSP. 234 4. Path Computation Considerations 236 In this section, we consider GMPLS constraints to be satisfied 237 in different cases of link attributes. When a LSP indicated in below 238 tables is created, the path computation must choose the route so as 239 to satisfy switching capability, encoding type and bandwidth at the 240 ingress link, transiting links and the egress link indicated in 241 columns next to the created LSP, considering underlying physical 242 constraints. Here, almost cases of GMPLS path computation 243 consideration are summarized in this document, however, some cases 244 will be added in a future version. 246 (1) TDM-Switch Capable 248 Table 1: Desired GMPLS Attributes in the Case of TDM-SC 250 +-------------+---------+------------+---------+------------------+ 251 |LSP attribute|Ingress |Transit |Egress |Remarks | 252 +---+---------+---------+------------+---------+------------------+ 253 | | |TDM | |TDM | | 254 | | +---------+ +---------+ | 255 |SC*|TDM |L2SC |TDM |L2SC | | 256 | | +---------+ +---------+ | 257 | | |PSC | |PSC | | 258 +---+---------+---------+------------+---------+ | 259 | |SONET/SDH|SONET/SDH|SONET/SDH |SONET/SDH|Specified in G.691| 260 | +---------+---------+------------+---------+ | 261 |Enc|Ethernet |Ethernet |SONET/SDH |Ethernet |Specified in IEEE | 262 | | | |or Ethernet | | | 263 | +---------+---------+------------+---------+ | 264 | |OTN* |OTN |OTN |OTN | | 265 +---+---------+---------+------------+---------+ | 266 |BW*|X |<=bw* |<=bw |<=bw | | 267 November 2007 269 +---+---------+---------+------------+---------+------------------+ 271 *SC in LSP means a desired switching type of LSP. 272 *OTN interfaces are equivalent to digital wrapper technology in this 273 document. 274 * BW is the desired bandwidth of the LSP 275 * bw is the bandwidth available on the link 277 In this case, since the interface with TDM SC supports sub-rate 278 switching, BW X can be equal to or less than bw of ingress, transit 279 and egress links, and must be larger than the minimum LSP bandwidth 280 in the interface switching capability descriptor. Sub-rate switching 281 is unsuited for a hierarchical LSP, because the lower-layer link 282 usually has larger granular bandwidth than that layer except PSC-x, 283 for example a TDM LSP with the desired bandwidth of OC-12 should not 284 use a lambda switching capable link with the bandwidth of OC-48 as a 285 transit link. In such a case, a lambda LSP as a forwarding adjacency 286 (FA) LSP is created on the lower (lambda) layer in advance, then the 287 FA-LSP [LSP-HIER] may be advertised as a TDM SC link. 289 (2) Lambda Switch Capable (LSC) 291 Table 2.1: The Case of End-Point(Ingress/Egress) Link Attributes 292 without Lambda Encoding 294 +-------------+---------+------------+---------+------------------+ 295 |LSP attribute|Ingress |Transit |Egress |Remarks | 296 +---+---------+---------+------------+---------+------------------+ 297 | | |LSC | |LSC | | 298 | | +---------+ +---------+ | 299 |SC |LSC |TDM |LSC |TDM | | 300 | | +---------+ +---------+ | 301 | | |L2SC | |L2SC | | 302 | | +---------+ +---------+ | 303 | | |PSC | |PSC | | 304 +---+---------+---------+------------+---------+[RFC4202] | 305 | |SONET/SDH|SONET/SDH|SONET/SDH |SONET/SDH|section 3.6, 3.9 | 306 | | | |or lambda | |Specified in G.691| 307 | +---------+---------+------------+---------+ | 308 |Enc|Ethernet |Ethernet |Ethernet |Ethernet |Specified in IEEE | 309 | | | |or lambda | | | 310 | +---------+---------+------------+---------+ | 311 | |OTN |OTN |OTN |OTN |Specified in G.709| 312 | | | |or lambda | | | 313 |---+---------+---------+------------+---------+ | 314 |BW |X |=bw |=bw |=bw | | 315 | | | |or *<=bw | | | 316 +---+---------+---------+------------+---------+------------------+ 317 November 2007 319 If an interface supports only a specific bit-rate and format such as 320 SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to 321 match bit-rate and its framing. 323 *In the case of an interface with a lambda encoding and a transparent 324 to bit-rate and framing, BW X must be equal to or less than bw. 326 Table 2.2: The Case of End-Point(Ingress/Egress) Link Attributes 327 with Lambda Encoding 329 +-------------+---------+------------+---------+------------------+ 330 |LSP attribute|Ingress |Transit |Egress |Remarks | 331 +---+---------+---------+------------+---------+------------------+ 332 | | |LSC | |LSC | | 333 | | +---------+ +---------+ | 334 |SC |LSC |TDM |LSC |TDM | | 335 | | +---------+ +---------+ | 336 | | |L2SC | |L2SC | | 337 | | +---------+ +---------+ | 338 | | |PSC | |PSC | | 339 +---+---------+---------+------------+---------+ | 340 | |lambda | |lambda | |[RFC4202] | 341 | +---------+ +------------+ |section 3.7, 3.10 | 342 |Enc|SONET/SDH| |SONET/SDH | |Specified in G.691| 343 | | | |or lambda | | | 344 | +---------+lambda +------------+lambda | | 345 | |Ethernet | |Ethernet | |Specified in IEEE | 346 | | | |or lambda | | | 347 | +---------+ +------------+ | | 348 | |OTN | |OTN | |Specified in G.709| 349 | | | |or lambda | | | 350 +---+---------+---------+------------+---------+ | 351 |BW |X |<=bw |=bw |<=bw | | 352 | | | |or *<=bw | | | 353 +---+---------+---------+------------+---------+------------------+ 355 If an interface supports only a specific bit-rate and format such as 356 SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to 357 match bit-rate and its framing. 359 *In the case of an interface with a lambda encoding and a transparent 360 to bit-rate and framing, BW X must be equal to or less than bw. 362 November 2007 364 Table 2.3: The Case of One End-Point (Ingress/Egress) Link 365 Attribute with Lambda Encoding 367 +-------------+---------+------------+---------+------------------+ 368 |LSP attribute|Ingress |Transit |Egress |Remarks | 369 +---+---------+---------+------------+---------+------------------+ 370 | | |LSC | |LSC | | 371 | | +---------+ +---------+ | 372 |SC |LSC |TDM |LSC |TDM | | 373 | | +---------+ +---------+ | 374 | | |L2SC | |L2SC | | 375 | | +---------+ +---------+ | 376 | | |PSC | |PSC | | 377 +---+---------+---------+------------+---------+[RFC4202] | 378 | |SONET/SDH| |SONET/SDH |SONET/SDH|section 3.6, 3.9 | 379 | | | |or lambda | |Specified in G.691| 380 | +---------+ +------------+---------+ | 381 |Enc|Ethernet |lambda |Ethernet |Ethernet |Specified in IEEE | 382 | | | |or lambda | | | 383 | +---------+ +------------+---------+ | 384 | |OTN | |OTN |OTN |Specified in G.709| 385 | | | |or lambda | | | 386 +---+---------+---------+------------+---------+ | 387 |BW |X |<=bw |=bw |=bw | | 388 | | | |or *<=bw | | | 389 +---+---------+---------+------------+---------+------------------+ 391 The case of ingress link with the specific encoding and egress link 392 with lambda encoding also follows the same manner. 394 If an interface supports only a specific bit-rate and format such as 395 SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to 396 match bit-rate and its framing. 398 *In the case of an interface with a lambda encoding and a transparent 399 to bit-rate and framing, BW X must be equal to or less than bw. 401 November 2007 403 (3) Fiber Switch Capable (FSC) 405 Table 3.1: The Case of End-Point(Ingress/Egress) Link Attributes 406 without Lambda or Fiber Encoding 408 +---+---------+---------+------------+---------+------------------+ 409 |LSP attribute|Ingress |Transit |Egress |Remarks | 410 +---+---------+---------+------------+---------+------------------+ 411 | | |FSC | |FSC | | 412 | | +---------+ +---------+ | 413 | | |LSC | |LSC | | 414 | | +---------+ +---------+ | 415 |SC |FSC |TDM |FSC |TDM | | 416 | | +---------+ +---------+ | 417 | | |L2SC | |L2SC | | 418 | | +---------+ +---------+ | 419 | | |PSC | |PSC | | 420 +---+---------+---------+------------+---------+[RFC4202] | 421 |Enc|SONET/SDH|SONET/SDH|SONET/SDH |SONET/SDH|section 3.6, 3.9 | 422 | | | |or lambda | |Specified in G.691| 423 | | | |or fiber | | | 424 | +---------+---------+------------+---------+ | 425 | |Ethernet |Ethernet |Ethernet |Ethernet |Specified in IEEE | 426 | | | |or lambda | | | 427 | | | |or fiber | | | 428 | +---------+---------+------------+---------+ | 429 | |OTN |OTN |OTN |OTN |Specified in G.709| 430 | | | |or lambda | | | 431 | | | |or fiber | | | 432 +---+---------+---------+------------+---------+ | 433 |BW |X |=bw |=bw |=bw | | 434 | | | |or *<=bw | | | 435 +---+---------+---------+------------+---------+------------------+ 437 If an interface supports only a specific bit-rate and format such as 438 SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to 439 match bit-rate and its framing. 441 November 2007 443 *In the case of an interface with a lambda or fiber encoding and a 444 transparent to bit-rate and framing, BW X must be equal to or less 445 than bw. 447 Table 3.2: The Case of End-Point(Ingress/Egress) Link Attributes with 448 Lambda or Fiber Encoding 450 +---+---------+---------+------------+---------+------------------+ 451 |LSP attribute|Ingress |Transit |Egress |Remarks | 452 +---+---------+---------+------------+---------+------------------+ 453 | | |FSC | |FSC | | 454 | | +---------+ +---------+ | 455 | | |LSC | |LSC | | 456 | | +---------+ +---------+ | 457 |SC |FSC |TDM |FSC |TDM | | 458 | | +---------+ +---------+ | 459 | | |L2SC | |L2SC | | 460 | | +---------+ +---------+ | 461 | | |PSC | |PSC | | 462 +---+---------+---------+------------+---------+[RFC4202] | 463 | |fiber |fiber |fiber |fiber |section 3.8 | 464 | +---------+---------+------------+---------+ | 465 |Enc|lambda | |lambda | |section 3.7, 3.10 | 466 | | | |or fiber | | | 467 | +---------+ +------------+ |section 3.6, 3.9 | 468 | |SONET/SDH| |SONET/SDH | |Specified in G.691| 469 | | | |or lambda | | | 470 | | |lambda |or fiber |lambda | | 471 | +---------+or fiber +------------+or fiber | | 472 | |Ethernet | |Ethernet | |Specified in IEEE | 473 | | | |or lambda | | | 474 | | | |or fiber | | | 475 | +---------+ +------------+ | | 476 | |OTN | |OTN | |Specified in G.709| 477 | | | |or lambda | | | 478 | | | |or fiber | | | 479 +---+---------+---------+------------+---------+ | 480 |BW |X |<=bw |=bw |<=bw | | 481 | | | |or *<=bw | | | 482 +---+---------+---------+------------+---------+------------------+ 483 November 2007 485 If an interface supports only a specific bit-rate and format such as 486 SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to 487 match bit-rate and its framing. 489 *In the case of an interface with a lambda or fiber encoding and a 490 transparent to bit-rate and framing, BW X must be equal to or less 491 than bw. 493 Table 3.3: The Case of One End-Point (Ingress/Egress) Link Attribute 494 with Lambda or Fiber Encoding 496 +---+---------+---------+------------+---------+------------------+ 497 |LSP attribute|Ingress |Transit |Egress |Remarks | 498 +---+---------+---------+------------+---------+------------------+ 499 | | |FSC | |FSC | | 500 | | +---------+ +---------+ | 501 | | |LSC | |LSC | | 502 | | +---------+ +---------+ | 503 |SC |FSC |TDM |FSC |TDM | | 504 | | +---------+ +---------+ | 505 | | |L2SC | |L2SC | | 506 | | +---------+ +---------+ | 507 | | |PSC | |PSC | | 508 +---+---------+---------+------------+---------+[RFC4202] | 509 |Enc|SONET/SDH| |SONET/SDH |SONET/SDH|section 3.6, 3.9 | 510 | | | |or lambda | |Specified in G.691| 511 | | | |or fiber | | | 512 | +---------+ +------------+---------+ | 513 | |Ethernet |lambda |Ethernet |Ethernet |Specified in IEEE | 514 | | |or fiber |or lambda | | | 515 | | | |or fiber | | | 516 | +---------+ +------------+---------+ | 517 | |OTN | |OTN |OTN |Specified in G.709| 518 | | | |or lambda | | | 519 | | | |or fiber | | | 520 +---+---------+---------+------------+---------+ | 521 |BW |X |<=bw |=bw |=bw | | 522 | | | |or *<=bw | | | 523 +---+---------+---------+------------+---------+------------------+ 525 The case of ingress link with the specific encoding and egress link 526 with lambda encoding also follows as the same manner. 528 November 2007 530 If an interface supports only a specific bit-rate and format such as 531 SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to 532 match bit-rate and its framing. 534 *In the case of an interface with a lambda encoding and a transparent 535 to bit-rate and framing, BW X must be equal to or less than bw. 537 Although the interface with FSC can switch the entire contents to 538 another interface, this interface should only be used for optical 539 wavelength or waveband switching. 541 (4) Layer 2 Switch Capable (L2SC) 543 The guideline for the calculation must be created after the 544 definition and discussion about L2SW are settled down. 546 (5) Packet Switch Capable (PSC) 548 Table 4: Desired GMPLS Attributes in the case of PSC 549 +-------------+---------+------------+---------+------------------+ 550 |LSP attribute|Ingress |Transit |Egress |Remarks | 551 +---+---------+---------+------------+---------+------------------+ 552 |SC |PSC |PSC |PSC |PSC | | 553 +---+---------+---------+------------+---------+ | 554 |Enc|Packet |Packet |Packet |Packet | | 555 +---+---------+---------+------------+---------+ | 556 |BW |X |<=bw |<=bw |<=bw | | 557 +---+---------+---------+------------+---------+------------------+ 559 Since the interface with PSC supports only packet-by-packet switching, 560 BW X must be equal to or less than bw, and must be larger than the 561 minimum LSP bandwidth. 563 These GMPLS constraints must be considered for computing paths and 564 creating GMPLS LSPs. 566 This document does not discuss domain based multilayer path 567 computation considerations where specific routing policies, which are 568 sometimes independent from the underlying domains and sometimes take 569 the underlying domains' policies into consideration, are required. 571 5. Security consideration 572 November 2007 574 Anything that can be done to change the output of a path 575 computation algorithm can significantly affect the operational 576 stability of a network, could force traffic to traverse undesirable 577 or costly links, and could place data into less secure parts of the 578 network. Therefore, the integrity of the path computation mechanism 579 is very significant in a GMPLS network. 581 The path computation algorithm, itself, and the mechanisms for 582 conveying computed paths to and between the LSRs in the network are 583 out of scope for this document. But misuse or confusion with respect 584 of the handling of the attributes described in this document could 585 leave a network open to various security attacks. In particular, if 586 there is a known mismatch between the interpretation or handling of 587 TE attributes within a network this might be exploited by an attacker 588 to cause disruption or to waste network resources in an integrated 589 multi-technology network. Therefore, network operators are 590 Recommended to use a consistent approach across the whole network. 592 6. Acknowledgements 594 Thanks to Adrian Farrel for his review of this document. 596 7. Intellectual Property Considerations 598 The IETF takes no position regarding the validity or scope of 599 any Intellectual Property Rights or other rights that might be 600 claimed to pertain to the implementation or use of the technology 601 described in this document or the extent to which any license under 602 such rights might or might not be available; nor does it represent 603 that it has made any independent effort to identify any such rights. 604 Information on the procedures with respect to rights in RFC documents 605 can be found in BCP 78 and BCP 79. 607 Copies of IPR disclosures made to the IETF Secretariat and any 608 assurances of licenses to be made available, or the result of an 609 attempt made to obtain a general license or permission for the use of 610 such proprietary rights by implementers or users of this 611 specification can be obtained from the IETF on-line IPR repository at 612 http://www.ietf.org/ipr. 614 The IETF invites any interested party to bring to its attention 615 any copyrights, patents or patent applications, or other proprietary 616 rights that may cover technology that may be required to implement 617 this standard. Please address the information to the IETF at 618 ietf-ipr@ietf.org. 620 November 2007 622 8. IANA Considerations 624 This document does not require any IANA consideration. 626 9. References 628 9.1 Normative References 630 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 631 Requirement Levels", BCP 14, RFC 2119, March 1997. 632 [RFC4202] K. Kompella and Y. Rekhter, "Routing Extensions in 633 Support of Generalized Multi-Protocol Label Switching", 634 RFC4202, October 2005. 635 [RFC4203] K. Kompella and Y. Rekhter, "OSPF Extensions in 636 Support of Generalized Multi-Protocol Label Switching", 637 RFC4203, October 2005. 639 9.2 Informative References 641 [RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered 642 Links in Resource ReSerVation Protocol - Traffic 643 Engineering (RSVP-TE)", RFC3477, January 2003. 644 [RFC3630] Katz, D., et al, "Traffic Engineering (TE) Extensions 645 to OSPF Version 2", RFC3630, September 2003. 646 [RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching 647 Architecture", RFC3945, October, 2004. 649 Author's Addresses 651 Tomohiro Otani 652 KDDI R&D Laboratories, Inc. 653 2-1-15 Ohara Fujimino-shi 654 Saitama, 356-8502 Japan 655 Phone: +81-49-278-7357 656 Email: otani@kddilabs.jp 658 Kenichi Ogaki 659 KDDI R&D Laboratories, Inc. 660 2-1-15 Ohara Fujimino-shi 661 Saitama, 356-8502 Japan 662 Phone: +81-49-278-7897 663 Email: ogaki@kddilabs.jp 665 Arthi Ayyangar 666 Nuova Systems 667 2600 San Tomas Expressway 668 Santa Clara, CA 95051 669 Email: arthi@nuovasystems.com 670 November 2007 672 Rajiv Papneja 673 Isocore 674 12359 Sunrise Valley Drive 675 Suite 100, Reston, VA 20191 US 676 Email: rpapneja@isocore.com 678 Kireeti Kompella 679 Juniper Networks 680 1194 N. Mathilda Ave. 681 Sunnyvale, CA 94089 US 682 Email: kireeti@juniper.net 684 Daniel King 685 Aria Networks Ltd. 686 44-45 Market Place 687 Chippenham, SN153HU UK 688 EMail: daniel.king@aria-networks.com 690 Document expiration 692 This document will be expired in May 2008, unless it is updated. 694 Full Copyright Statement 696 Copyright (C) The IETF Trust (2007). 698 This document is subject to the rights, licenses and restrictions 699 contained in BCP 78, and except as set forth therein, the authors 700 retain all their rights. 702 This document and the information contained herein are provided on an 703 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 704 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 705 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 706 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 707 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 708 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.