idnits 2.17.1 draft-otani-ccamp-gmpls-cspf-constraints-06.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 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 595. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 601. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 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 274, but not defined == Unused Reference: 'RFC2119' is defined on line 607, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Internet Draft Tomohiro Otani (Editor) 3 Intended status: Informational Kenichi Ogaki (Editor) 4 Expires: January 2008 KDDI R&D Labs 5 Daniel King(Editor) 6 Aria Networks 8 July 20077 10 Considering Generalized Multiprotocol Label Switching Traffic 11 Engineering Attributes During Path Computation 13 Document: draft-otani-ccamp-gmpls-cspf-constraints-06.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 January 2008 1 52 Table of Contents 54 Status of this Memo................................................1 55 Abstract...........................................................1 56 1. Introduction....................................................3 57 2. Problem Statements..............................................3 58 3. Assumed Network Model...........................................4 59 4. Path Computation Considerations.................................6 60 5. Security Consideration.........................................13 61 6. Acknowledgements...............................................14 62 7. Intellectual Property Considerations...........................14 63 8. References.....................................................14 65 T. Otani et al. Expires January 2008 2 66 1. Introduction 68 A network is, in general, controlled and managed taking into account 69 various attributes of the underlying technologies of the physical and 70 logical links and nodes. In a network operated using Generalized 71 Multiprotocol Label Switching (GMPLS) protocols, many of these 72 Traffic Engineering (TE) attributes are advertised using routing 73 protocols [RFC3945], [RFC4202]. 75 To establish a GMPLS Label Switched Path (LSP) it is necessary 76 to compute a route or path for that LSP either hop-by-hop or by the 77 pre-calculation of part or all of the path. In order that the route 78 selected is capable of satisfying the requirements of the user or 79 application that will use the LSP the computation must be constrained 80 by a set of LSP-specific requirements and the TE attributes 81 advertised within the network. Further, considerations of technology 82 and node or link capabilities may also provide restrictions to the 83 feasibility of LSP establishment on certain routes, and this can be 84 deduced from the TE attributes advertised within the network and used 85 by the path computation algorithms to select only viable routes. 87 In a mixed, integrated network (for example, one containing 88 optical switches and packet routers) these constraints may vary and 89 are understood differently for different equipment and different LSPs. 90 This document provides guidelines to facilitate path computation for 91 GMPLS LSPs by summarizing how GMPLS TE attributes on ingress links, 92 transit links, and egress links may be treated as path computation 93 constraints to determine the route of a GMPLS Label Switched Path 94 (LSP). 96 2. Problem Statements 98 A GMPLS network which is composed of multiple nodes has each 99 capability in each node. Therefore, if each node in the network does 100 not have uniformed way for TE constraints in a path calculation, an 101 establishment for GMPLS LSPs may fail in the path computation or 102 signaling despite of sufficient resources existence. For the 103 capability of each TE-link, GMPLS has such a specification as ISCD 104 (Interface Switching Capability Descriptor) defined in [RFC4202]. On 105 the contrary, constraint conditions for end-to-end path calculation 106 for GMPLS LSPs are not clearly specified. To address the issue of an 107 LSP establishment, the selection of TE constraints for path 108 calculation must be clearly defined. 110 Figure 1 shows a typical network example composed of routers and PXCs 111 (photonic cross connects). To exactly match TE attributes of all 112 transit links to a desired LSP's one, a TE-link between two PXCs must 113 have multiple ISCDs of Ethernet and SONET/SDH encoding-types 114 following specification [RFC4202] to support LSPs with both encoding- 115 types. However, it is not efficient because PXC itself does not have 117 T. Otani et al. Expires January 2008 3 118 such a capability and simply switch lambda only. To correctly 119 establish the LSP in such a network, the constraint consideration for 120 end-to-end path calculation must be clearly defined. 122 Router1 Router4 123 \ / 124 \ / 125 (Ethernet) (Ethernet) 126 \ / 127 \ / 128 PXC1--(Lambda)--PXC2--(Lambda)--PXC3 129 / \ 130 / \ 131 (SONET/SDH) (SONET/SDH) 132 / \ 133 / \ 134 Router2 Router4 136 *(): Encoding type 137 Figure 1: example network 139 3. Assumed Network Model 141 3.1 GMPLS TE Attributes Consideration for Path Calculation 143 For path computation to establish GMPLS LSPs correctly, various GMPLS 144 attributes [RFC4202], [RFC4203] of links as well as nodes, as 145 indicated below, must be taken into account in a GMPLS network 146 environment in addition to TE attributes of packet based network 147 [RFC3630]. 149 (1) Encoding-type: Synchronous Optical Network 150 (SONET)/Synchronous Digital Hierarchy (SDH), Lambda, Ethernet, 151 etc. 152 (2) Switching capability: Time Division Multiplex (TDM), Lambda, 153 Fiber, etc. 154 (3) Bandwidth: OC-192, OC-48, GbE, 10GbE, etc. 156 These logical attributes have a very tight relationship with 157 underlying physical technologies such as SONET/SDH, Optical Transport 158 Network (OTN) or Ethernet in terms of links, and all-optical switches, 159 SONET/SDH-basis digital cross connect or electrical-basis optical 160 switches in terms of nodes. Therefore, the GMPLS LSPs must satisfy 161 logical constrains as well as corresponding physical constraints. 162 These constraints are sometimes differently understood among 163 different layers, and a logically computed GMPLS LSP may violate the 164 physical constraints, therefore, a consistent guideline to solve this 165 issue should be formulated. 167 T. Otani et al. Expires January 2008 4 168 3.2 Considered Network Model 170 Figure 2 depicts a typical GMPLS network, consisting of an ingress 171 link, a transit link as well as an egress link, to investigate a 172 consistent guideline for GMPLS path computation. Each link at each 173 interface has its own switching capability, encoding type and 174 bandwidth. 175 The consideration here is based on a single domain GMPLS network, but 176 the analysis maybe applicable to an inter-domain GMPLS networks. 178 Ingress Transit Egress 179 +-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+ 180 |Node1|------------>|Node2|------------>|Node3|------------>|Node4| 181 | |<------------| |<------------| |<------------| | 182 +-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+ 184 Figure 2: GMPLS Network Model 186 For the simplicity of the analysis in path consideration, the below 187 basic assumptions are made when the LSP is created. 189 (1) Switching capabilities (SC) of outgoing links from the 190 ingress and egress nodes (link1-2 and link4-3 in Figure 1) 191 must be consistent with each other. 192 (2) SC of all transit links including incoming links to the 193 ingress and egress nodes (link2-1 and link3-4) should be 194 consistent with switching type of a LSP to be created. 195 (3) Encoding-types of all transit links should be consistent 196 with encoding type of a LSP to be created. 198 A GMPLS network maybe a multi-layer network, which is composed of 199 multiple nodes with different switching capabilities and interface 200 encoding types. Therefore, a hierarchical structure may be considered 201 in path computation. In such a case, the combination between the 202 switching type and encoding type of a desired LSP, and those of all 203 transit links described as the table in following section may be 204 acceptable. One of advertised multiple interface switching capability 205 descriptors for the same link [RFC4202] should be also appropriately 206 chosen as the attribute for the link. 208 Bandwidth of each TE link is maximum LSP bandwidth in interface 209 switching capability descriptor at the priority for a desired LSP 210 [RFC4203], and encoding-types of incoming and outgoing links on the 211 same interface (for example, link1-2 and link2-1) should be 212 consistent with each other. 214 In case that the network is comprised of numbered links and 215 unnumbered links [RFC3477], an ingress node, who is able to support 217 T. Otani et al. Expires January 2008 5 218 numbered links and unnumbered links may choose both links being part 219 of the same desired LSP. 221 4. Path Computation Considerations 223 In this section, we consider GMPLS constraints to be satisfied 224 in different cases of link attributes. When a LSP indicated in below 225 tables is created, the path computation must choose the route so as 226 to satisfy switching capability, encoding type and bandwidth at the 227 ingress link, transiting links and the egress link indicated in 228 columns next to the created LSP, considering underlying physical 229 constraints. Here, almost cases of GMPLS path computation 230 consideration are summarized in this document, however, some cases 231 will be added in a future version. 233 (1) TDM-Switch Capable 235 Table 1: Desired GMPLS Attributes in the Case of TDM-SC 237 +-------------+---------+------------+---------+------------------+ 238 |LSP attribute|Ingress |Transit |Egress |Remarks | 239 +---+---------+---------+------------+---------+------------------+ 240 | | |TDM | |TDM | | 241 | | +---------+ +---------+ | 242 |SC*|TDM |L2SC |TDM |L2SC | | 243 | | +---------+ +---------+ | 244 | | |PSC | |PSC | | 245 +---+---------+---------+------------+---------+ | 246 | |SONET/SDH|SONET/SDH|SONET/SDH |SONET/SDH|Specified in G.691| 247 | +---------+---------+------------+---------+ | 248 |Enc|Ethernet |Ethernet |SONET/SDH |Ethernet |Specified in IEEE | 249 | | | |or Ethernet | | | 250 | +---------+---------+------------+---------+ | 251 | |OTN* |OTN |OTN |OTN | | 252 +---+---------+---------+------------+---------+ | 253 |BW*|X |<=bw* |<=bw |<=bw | | 254 +---+---------+---------+------------+---------+------------------+ 256 *SC in LSP means a desired switching type of LSP. 257 *OTN interfaces are equivalent to digital wrapper technology in this 258 document. 259 * BW is the desired bandwidth of the LSP 260 * bw is the bandwidth available on the link 262 In this case, since the interface with TDM SC supports sub-rate 263 switching, BW X can be equal to or less than bw of ingress, transit 264 and egress links, and must be larger than the minimum LSP bandwidth 265 in the interface switching capability descriptor. Sub-rate switching 267 T. Otani et al. Expires January 2008 6 268 is unsuited for a hierarchical LSP, because the lower-layer link 269 usually has larger granular bandwidth than that layer except PSC-x, 270 for example a TDM LSP with the desired bandwidth of OC-12 should not 271 use a lambda switching capable link with the bandwidth of OC-48 as a 272 transit link. In such a case, a lambda LSP as a forwarding adjacency 273 (FA) LSP is created on the lower (lambda) layer in advance, then the 274 FA-LSP [LSP-HIER] may be advertised as a TDM SC link. 276 (2) Lambda Switch Capable (LSC) 278 Table 2.1: The Case of End-Point(Ingress/Egress) Link Attributes 279 without Lambda Encoding 281 +-------------+---------+------------+---------+------------------+ 282 |LSP attribute|Ingress |Transit |Egress |Remarks | 283 +---+---------+---------+------------+---------+------------------+ 284 | | |LSC | |LSC | | 285 | | +---------+ +---------+ | 286 |SC |LSC |TDM |LSC |TDM | | 287 | | +---------+ +---------+ | 288 | | |L2SC | |L2SC | | 289 | | +---------+ +---------+ | 290 | | |PSC | |PSC | | 291 +---+---------+---------+------------+---------+[RFC4202] | 292 | |SONET/SDH|SONET/SDH|SONET/SDH |SONET/SDH|section 3.6, 3.9 | 293 | | | |or lambda | |Specified in G.691| 294 | +---------+---------+------------+---------+ | 295 |Enc|Ethernet |Ethernet |Ethernet |Ethernet |Specified in IEEE | 296 | | | |or lambda | | | 297 | +---------+---------+------------+---------+ | 298 | |OTN |OTN |OTN |OTN |Specified in G.709| 299 | | | |or lambda | | | 300 |---+---------+---------+------------+---------+ | 301 |BW |X |=bw |=bw |=bw | | 302 | | | |or *<=bw | | | 303 +---+---------+---------+------------+---------+------------------+ 304 If an interface supports only a specific bit-rate and format such as 305 SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to 306 match bit-rate and its framing. 308 *In the case of an interface with a lambda encoding and a transparent 309 to bit-rate and framing, BW X must be equal to or less than bw. 311 T. Otani et al. Expires January 2008 7 312 Table 2.2: The Case of End-Point(Ingress/Egress) Link Attributes 313 with Lambda Encoding 315 +-------------+---------+------------+---------+------------------+ 316 |LSP attribute|Ingress |Transit |Egress |Remarks | 317 +---+---------+---------+------------+---------+------------------+ 318 | | |LSC | |LSC | | 319 | | +---------+ +---------+ | 320 |SC |LSC |TDM |LSC |TDM | | 321 | | +---------+ +---------+ | 322 | | |L2SC | |L2SC | | 323 | | +---------+ +---------+ | 324 | | |PSC | |PSC | | 325 +---+---------+---------+------------+---------+ | 326 | |lambda | |lambda | |[RFC4202] | 327 | +---------+ +------------+ |section 3.7, 3.10 | 328 |Enc|SONET/SDH| |SONET/SDH | |Specified in G.691| 329 | | | |or lambda | | | 330 | +---------+lambda +------------+lambda | | 331 | |Ethernet | |Ethernet | |Specified in IEEE | 332 | | | |or lambda | | | 333 | +---------+ +------------+ | | 334 | |OTN | |OTN | |Specified in G.709| 335 | | | |or lambda | | | 336 +---+---------+---------+------------+---------+ | 337 |BW |X |<=bw |=bw |<=bw | | 338 | | | |or *<=bw | | | 339 +---+---------+---------+------------+---------+------------------+ 341 If an interface supports only a specific bit-rate and format such as 342 SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to 343 match bit-rate and its framing. 345 *In the case of an interface with a lambda encoding and a transparent 346 to bit-rate and framing, BW X must be equal to or less than bw. 348 T. Otani et al. Expires January 2008 8 349 Table 2.3: The Case of One End-Point (Ingress/Egress) Link 350 Attribute with Lambda Encoding 352 +-------------+---------+------------+---------+------------------+ 353 |LSP attribute|Ingress |Transit |Egress |Remarks | 354 +---+---------+---------+------------+---------+------------------+ 355 | | |LSC | |LSC | | 356 | | +---------+ +---------+ | 357 |SC |LSC |TDM |LSC |TDM | | 358 | | +---------+ +---------+ | 359 | | |L2SC | |L2SC | | 360 | | +---------+ +---------+ | 361 | | |PSC | |PSC | | 362 +---+---------+---------+------------+---------+[RFC4202] | 363 | |SONET/SDH| |SONET/SDH |SONET/SDH|section 3.6, 3.9 | 364 | | | |or lambda | |Specified in G.691| 365 | +---------+ +------------+---------+ | 366 |Enc|Ethernet |lambda |Ethernet |Ethernet |Specified in IEEE | 367 | | | |or lambda | | | 368 | +---------+ +------------+---------+ | 369 | |OTN | |OTN |OTN |Specified in G.709| 370 | | | |or lambda | | | 371 +---+---------+---------+------------+---------+ | 372 |BW |X |<=bw |=bw |=bw | | 373 | | | |or *<=bw | | | 374 +---+---------+---------+------------+---------+------------------+ 376 The case of ingress link with the specific encoding and egress link 377 with lambda encoding also follows the same manner. 379 If an interface supports only a specific bit-rate and format such as 380 SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to 381 match bit-rate and its framing. 383 *In the case of an interface with a lambda encoding and a transparent 384 to bit-rate and framing, BW X must be equal to or less than bw. 386 T. Otani et al. Expires January 2008 9 387 (3) Fiber Switch Capable (FSC) 389 Table 3.1: The Case of End-Point(Ingress/Egress) Link Attributes 390 without Lambda or Fiber Encoding 392 +---+---------+---------+------------+---------+------------------+ 393 |LSP attribute|Ingress |Transit |Egress |Remarks | 394 +---+---------+---------+------------+---------+------------------+ 395 | | |FSC | |FSC | | 396 | | +---------+ +---------+ | 397 | | |LSC | |LSC | | 398 | | +---------+ +---------+ | 399 |SC |FSC |TDM |FSC |TDM | | 400 | | +---------+ +---------+ | 401 | | |L2SC | |L2SC | | 402 | | +---------+ +---------+ | 403 | | |PSC | |PSC | | 404 +---+---------+---------+------------+---------+[RFC4202] | 405 |Enc|SONET/SDH|SONET/SDH|SONET/SDH |SONET/SDH|section 3.6, 3.9 | 406 | | | |or lambda | |Specified in G.691| 407 | | | |or fiber | | | 408 | +---------+---------+------------+---------+ | 409 | |Ethernet |Ethernet |Ethernet |Ethernet |Specified in IEEE | 410 | | | |or lambda | | | 411 | | | |or fiber | | | 412 | +---------+---------+------------+---------+ | 413 | |OTN |OTN |OTN |OTN |Specified in G.709| 414 | | | |or lambda | | | 415 | | | |or fiber | | | 416 +---+---------+---------+------------+---------+ | 417 |BW |X |=bw |=bw |=bw | | 418 | | | |or *<=bw | | | 419 +---+---------+---------+------------+---------+------------------+ 421 If an interface supports only a specific bit-rate and format such as 422 SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to 423 match bit-rate and its framing. 425 *In the case of an interface with a lambda or fiber encoding and a 426 transparent to bit-rate and framing, BW X must be equal to or less 427 than bw. 429 T. Otani et al. Expires January 2008 10 430 Table 3.2: The Case of End-Point(Ingress/Egress) Link Attributes with 431 Lambda or Fiber Encoding 433 +---+---------+---------+------------+---------+------------------+ 434 |LSP attribute|Ingress |Transit |Egress |Remarks | 435 +---+---------+---------+------------+---------+------------------+ 436 | | |FSC | |FSC | | 437 | | +---------+ +---------+ | 438 | | |LSC | |LSC | | 439 | | +---------+ +---------+ | 440 |SC |FSC |TDM |FSC |TDM | | 441 | | +---------+ +---------+ | 442 | | |L2SC | |L2SC | | 443 | | +---------+ +---------+ | 444 | | |PSC | |PSC | | 445 +---+---------+---------+------------+---------+[RFC4202] | 446 | |fiber |fiber |fiber |fiber |section 3.8 | 447 | +---------+---------+------------+---------+ | 448 |Enc|lambda | |lambda | |section 3.7, 3.10 | 449 | | | |or fiber | | | 450 | +---------+ +------------+ |section 3.6, 3.9 | 451 | |SONET/SDH| |SONET/SDH | |Specified in G.691| 452 | | | |or lambda | | | 453 | | |lambda |or fiber |lambda | | 454 | +---------+or fiber +------------+or fiber | | 455 | |Ethernet | |Ethernet | |Specified in IEEE | 456 | | | |or lambda | | | 457 | | | |or fiber | | | 458 | +---------+ +------------+ | | 459 | |OTN | |OTN | |Specified in G.709| 460 | | | |or lambda | | | 461 | | | |or fiber | | | 462 +---+---------+---------+------------+---------+ | 463 |BW |X |<=bw |=bw |<=bw | | 464 | | | |or *<=bw | | | 465 +---+---------+---------+------------+---------+------------------+ 467 If an interface supports only a specific bit-rate and format such as 468 SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to 469 match bit-rate and its framing. 471 *In the case of an interface with a lambda or fiber encoding and a 472 transparent to bit-rate and framing, BW X must be equal to or less 473 than bw. 475 T. Otani et al. Expires January 2008 11 476 Table 3.3: The Case of One End-Point (Ingress/Egress) Link Attribute 477 with Lambda or Fiber Encoding 479 +---+---------+---------+------------+---------+------------------+ 480 |LSP attribute|Ingress |Transit |Egress |Remarks | 481 +---+---------+---------+------------+---------+------------------+ 482 | | |FSC | |FSC | | 483 | | +---------+ +---------+ | 484 | | |LSC | |LSC | | 485 | | +---------+ +---------+ | 486 |SC |FSC |TDM |FSC |TDM | | 487 | | +---------+ +---------+ | 488 | | |L2SC | |L2SC | | 489 | | +---------+ +---------+ | 490 | | |PSC | |PSC | | 491 +---+---------+---------+------------+---------+[RFC4202] | 492 |Enc|SONET/SDH| |SONET/SDH |SONET/SDH|section 3.6, 3.9 | 493 | | | |or lambda | |Specified in G.691| 494 | | | |or fiber | | | 495 | +---------+ +------------+---------+ | 496 | |Ethernet |lambda |Ethernet |Ethernet |Specified in IEEE | 497 | | |or fiber |or lambda | | | 498 | | | |or fiber | | | 499 | +---------+ +------------+---------+ | 500 | |OTN | |OTN |OTN |Specified in G.709| 501 | | | |or lambda | | | 502 | | | |or fiber | | | 503 +---+---------+---------+------------+---------+ | 504 |BW |X |<=bw |=bw |=bw | | 505 | | | |or *<=bw | | | 506 +---+---------+---------+------------+---------+------------------+ 508 The case of ingress link with the specific encoding and egress link 509 with lambda encoding also follows as the same manner. 511 If an interface supports only a specific bit-rate and format such as 512 SONET/SDH or Ethernet encoding, BW X must be equal to bw so as to 513 match bit-rate and its framing. 515 *In the case of an interface with a lambda encoding and a transparent 516 to bit-rate and framing, BW X must be equal to or less than bw. 518 Although the interface with FSC can switch the entire contents to 519 another interface, this interface should only be used for optical 520 wavelength or waveband switching. 522 T. Otani et al. Expires January 2008 12 523 (4) Layer 2 Switch Capable (L2SC) 525 The guideline for the calculation must be created after the 526 definition and discussion about L2SW are settled down. 528 (5) Packet Switch Capable (PSC) 530 Table 4: Desired GMPLS Attributes in the case of PSC 531 +-------------+---------+------------+---------+------------------+ 532 |LSP attribute|Ingress |Transit |Egress |Remarks | 533 +---+---------+---------+------------+---------+------------------+ 534 |SC |PSC |PSC |PSC |PSC | | 535 +---+---------+---------+------------+---------+ | 536 |Enc|Packet |Packet |Packet |Packet | | 537 +---+---------+---------+------------+---------+ | 538 |BW |X |<=bw |<=bw |<=bw | | 539 +---+---------+---------+------------+---------+------------------+ 541 Since the interface with PSC supports only packet-by-packet switching, 542 BW X must be equal to or less than bw, and must be larger than the 543 minimum LSP bandwidth. 545 These GMPLS constraints must be considered for computing paths and 546 creating GMPLS LSPs. 548 This document does not discuss domain based multilayer path 549 computation considerations where specific routing policies, which are 550 sometimes independent from the underlying domains and sometimes take 551 the underlying domains' policies into consideration, are required. 553 5. Security consideration 555 Anything that can be done to change the output of a path 556 computation algorithm can significantly affect the operational 557 stability of a network, could force traffic to traverse undesirable 558 or costly links, and could place data into less secure parts of the 559 network. Therefore, the integrity of the path computation mechanism 560 is very significant in a GMPLS network. 562 The path computation algorithm, itself, and the mechanisms for 563 conveying computed paths to and between the LSRs in the network are 564 out of scope for this document. But misuse or confusion with respect 565 of the handling of the attributes described in this document could 566 leave a network open to various security attacks. In particular, if 567 there is a known mismatch between the interpretation or handling of 568 TE attributes within a network this might be exploited by an attacker 569 to cause disruption or to waste network resources in an integrated 571 T. Otani et al. Expires January 2008 13 572 multi-technology network. Therefore, network operators are 573 Recommended to use a consistent approach across the whole network. 575 6. Acknowledgements 577 Thanks to Adrian Farrel for his review of this document. 579 7. Intellectual Property Considerations 581 The IETF takes no position regarding the validity or scope of 582 any Intellectual Property Rights or other rights that might be 583 claimed to pertain to the implementation or use of the technology 584 described in this document or the extent to which any license under 585 such rights might or might not be available; nor does it represent 586 that it has made any independent effort to identify any such rights. 587 Information on the procedures with respect to rights in RFC documents 588 can be found in BCP 78 and BCP 79. 590 Copies of IPR disclosures made to the IETF Secretariat and any 591 assurances of licenses to be made available, or the result of an 592 attempt made to obtain a general license or permission for the use of 593 such proprietary rights by implementers or users of this 594 specification can be obtained from the IETF on-line IPR repository at 595 http://www.ietf.org/ipr. 597 The IETF invites any interested party to bring to its attention 598 any copyrights, patents or patent applications, or other proprietary 599 rights that may cover technology that may be required to implement 600 this standard. Please address the information to the IETF at 601 ietf-ipr@ietf.org. 603 8. References 605 8.1 Normative References 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, March 1997. 609 [RFC4202] K. Kompella and Y. Rekhter, "Routing Extensions in 610 Support of Generalized Multi-Protocol Label 611 Switching", RFC4202, October 2005. 612 [RFC4203] K. Kompella and Y. Rekhter, "OSPF Extensions in 613 Support of Generalized Multi-Protocol Label 614 Switching", RFC4203, October 2005. 616 8.2 Informative References 618 [RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered 619 Links in Resource ReSerVation Protocol - Traffic 620 Engineering (RSVP-TE)", RFC3477, January 2003. 622 T. Otani et al. Expires January 2008 14 624 [RFC3630] Katz, D., et al, "Traffic Engineering (TE) Extensions 625 to OSPF Version 2", RFC3630, September 2003. 626 [RFC3945] E. Mannie, "Generalized Multi-Protocol Label 627 Switching Architecture", RFC3945, October, 2004. 629 Authors' Addresses 631 Tomohiro Otani 632 KDDI R&D Laboratories, Inc. 633 2-1-15 Ohara Fujimino-shi 634 Saitama, 356-8502 Japan 635 Phone: +81-49-278-7357 636 Email: otani@kddilabs.jp 638 Kenichi Ogaki 639 KDDI R&D Laboratories, Inc. 640 2-1-15 Ohara Fujimino-shi 641 Saitama, 356-8502 Japan 642 Phone: +81-49-278-7897 643 Email: ogaki@kddilabs.jp 645 Arthi Ayyangar 646 Nuova Systems 647 2600 San Tomas Expressway 648 Santa Clara, CA 95051 649 Email: arthi@nuovasystems.com 651 Rajiv Papneja 652 Isocore 653 12359 Sunrise Valley Drive 654 Suite 100, Reston, VA 20191 US 655 Email: rpapneja@isocore.com 657 Kireeti Kompella 658 Juniper Networks 659 1194 N. Mathilda Ave. 660 Sunnyvale, CA 94089 US 661 Email: kireeti@juniper.net 663 Daniel King 664 Aria Networks Ltd. 665 44-45 Market Place 666 Chippenham, SN153HU UK 667 EMail: daniel.king@aria-networks.com 669 Document expiration 671 This document will be expired in January 2008, unless it is updated. 673 T. Otani et al. Expires January 2008 15 674 Full Copyright Statement 676 Copyright (C) The IETF Trust (2007). 678 This document is subject to the rights, licenses and restrictions 679 contained in BCP 78, and except as set forth therein, the authors 680 retain all their rights. 682 This document and the information contained herein are provided on an 683 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 684 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 685 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 686 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 687 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 688 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 690 T. Otani et al. Expires January 2008 16