idnits 2.17.1 draft-many-inference-srlg-02.txt: -(187): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(367): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(422): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(423): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(620): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(750): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(756): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(764): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 36 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 59 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([IPO-Frame]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (November 2001) is 8196 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) == Missing Reference: 'IPO-Frame' is mentioned on line 53, but not defined -- Looks like a reference, but probably isn't: '1' on line 329 -- Looks like a reference, but probably isn't: '2' on line 242 == Missing Reference: 'I' is mentioned on line 237, but not defined == Unused Reference: 'IEEE-ORL' is defined on line 750, but no explicit reference was found in the text == Unused Reference: 'MPLS-BUNDLE' is defined on line 763, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-ospf-gmpls-extensions-00 == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-04 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'GMPLS-ISIS') -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-ORL' -- Possible downref: Normative reference to a draft: ref. 'IPO-FRAME' == Outdated reference: A later version (-05) exists of draft-ietf-ipo-impairments-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ipo-impairments (ref. 'IPO-IMP') -- Possible downref: Normative reference to a draft: ref. 'MPLS-BUNDLE' -- Possible downref: Non-RFC (?) normative reference: ref. 'SRLG-RTG' Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Working Group D. Papadimitriou 3 Internet Draft F. Poppe 4 Document: draft-many-inference-srlg-02.txt J. Jones 5 Category: Internet Draft S. Venkatachalam 6 Expires: May 2002 Alcatel 8 S. Dharanikota 9 R. Jain 10 Nayna Networks 12 R. Hartani 13 Caspian Networks 15 D. Griffith 16 NIST 18 Yong Xue 19 UUNet 21 November 2001 23 Inference of Shared Risk Link Groups 25 draft-many-inference-srlg-02.txt 27 Status of this Memo 29 This document is an Internet-Draft and is in full conformance with 30 all provisions of Section 10 of RFC2026 32 This document is an Internet-Draft and is in full conformance with 33 all provisions of Section 10 of RFC2026 except that the right to 34 produce derivative works is not granted. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. Internet-Drafts are draft documents valid for a maximum of 40 six months and may be updated, replaced, or obsoleted by other 41 documents at any time. It is inappropriate to use Internet-Drafts as 42 reference material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 D.Papadimitriou et al. - Expires May 2002 1 51 Abstract 53 The Shared Risk Link Group (SRLG) concept introduced in [IPO-Frame] 54 is considered as one of the most important criteria concerning the 55 constrained-based path computation of optical channel routes. By 56 applying the SRLG constraint criteria to the constrained-based path 57 computation, one can select a route taking into account resource and 58 logical structure disjointness that implies a lower probability of 59 simultaneous lightpath failure. This contribution describes the 60 various physical and logical resource types considered in the SRLG 61 concept. The proposed model focuses on the inference of SRLG 62 information between the network physical layers as well as logical 63 structures such as geographical locations. The main applications of 64 the proposed model are related to the Constraint-based Shortest Path 65 First (CSPF) algorithm for optical channel route computation and the 66 aggregation of the SRLG information flooded throughout traffic 67 engineering extensions of the IGP routing protocols (such as OSPF 68 and IS-IS). 70 1. Introduction 72 Many proposals include the SRLG concept when considering the 73 disjointness of the constraint-based path computation for optical 74 channel routes. In optical domains this concept of SRLG is used for 75 deriving a path, which is disjoint from the physical resource and 76 logical topology point-of-view. The SRLG concept and the 77 corresponding requirements have already been described in [IPO-IMP] 78 while considering physical network topology and associated risks. 79 Within the scope of this document, these requirements can be 80 summarized as follows: 81 1. The SRLG encoding mechanism should reduce the path computation 82 complexity. 83 2. The SRLG information flooding should be scoped to reduce the 84 amount of information that is sent across domains. 85 3. The SRLG encoding should accommodate the physical and logical 86 restrictions imposed on the diversity requirements. 88 However, the definition of SRLG in the current format as described 89 in [GMPLS-OSPF] and [GMPLS-ISIS] does not provide: 90 1. The relationship between logical structures or physical resources 91 For example, a fiber could be part of a sequence of fiber 92 segments, which is included in a given geographical region. 93 2. The risk assessment during path computation implying the 94 allocation of a conditional failure probabilities with the SRLGs 95 3. The analysis of the specifications of constraint-based path 96 computation and path re-optimization taking SRLG information into 97 account. 99 The model described in this document proposes a technique to compute 100 the SRLG with respect to a given risk type. This is achieved by 101 identifying for a given physical layer the resources belonging to an 102 SRLG. The proposed model also permits to compute the dependencies of 104 D.Papadimitriou et al. � Internet Draft - Expires May 2002 2 105 these resources on the resources belonging to lower physical layers. 106 The result of the computation also enables to determine the risk 107 associated to each of the SRLGs. 109 The remainder of this memo is organized as follows. In section 3, we 110 present the hierarchical model of the resources and the 111 corresponding SRLG encoding. In section 4, we discuss the use of 112 such a model for the risk assessment for the path computation. 113 Future work is proposed in section 5, which is followed by 114 references in section 6. Appendix 1 provides an elaborate discussion 115 on the inference of SRLGs. 117 2. Conventions used in this document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 121 this document are to be interpreted as described in RFC-2119 [1]. 123 3. Hierarchical Model 125 The model described in this proposal includes two hierarchies 126 defined as follows: 128 - Physical hierarchy, which is related to the fiber topology (more 129 generally the physical resources) of the optical network including 130 the wavelengths built on top of this physical topology. 132 - Logical hierarchy, which is related to the geographical topology 133 of the network. 135 Between these two hierarchies, the nodes such as Optical Cross- 136 Connect (OXC) and Photonic Cross-Connect (PXC) constitute the 137 boundary layer. Each of these concepts is elaborated in the 138 following sections. 140 The encoding of the SRLG could be either mapped on this hierarchical 141 model or simply use a flat encoding scheme. Both methods seam 142 feasible. Difference between both approaches relies on the extended 143 usage of the SRLGs in the context of diverse route computation (i.e. 144 path disjointness). Since a link can belong to more than one SRLG, 145 an SRLG identifier list (i.e. the SRLG Sub-TLV), as described in 146 [GMPLS-OSPF] and [GMPLS-ISIS] is associated with the link to which 147 this link belongs (i.e. the SRLG Sub-TLV is defined as a Sub-TLV of 148 the Link TLV). This results in a linear, unordered and non- 149 structured information from which the underlying structure cannot be 150 deduced. 152 Consequently, either a type field indicating the type of resource 153 (or logical structure) to which this SRLG identifier refers extends 154 the flat encoding scheme or the encoding itself translates the 155 underlying hierarchical structure. Worth mentioning here that an 156 hierarchical encoding (since depending on the physical layer which 157 is by definition static) needs an additional mapping structure in 159 D.Papadimitriou et al. � Internet Draft - Expires May 2002 3 160 order to keep the relationship with link identifiers. Nevertheless, 161 the computational model developed in Appendix 1 does not depend on 162 the encoding scheme. 164 3.1 Physical Hierarchy (or Network Resource Hierarchy) 166 The network (physical) resource model considered in the inference of 167 the Shared Risk Link Groups (SRLGs) is based on concepts detailed in 168 [IPO-FRAME] and [IPO-IMP]. The concepts around network resource 169 hierarchy developed within this document are based on the following 170 definitions: 171 - Sub-Channel: a dedicated container included within a given channel 172 uniquely identifies a sub-channel 173 - Channel (or wavelength): a channel is uniquely identified by a 174 dedicated wavelength (i.e. lambda) 175 - Fiber Link: a fiber connects two node ports communicating through 176 one optical channel or more than one optical channel if the node 177 interfaces support Wavelength Division Multiplexing (WDM). 178 - Fiber Sub-segment: grouping of several fiber links forms a fiber 179 sub-segment. 180 - Fiber Segment: a fiber segment includes a collection of fiber sub- 181 segments. 182 - Fiber Trunks: a fiber trunk is a sequence of fiber segments, 183 including one or more fiber segments starting and terminating at 184 the same node. 186 The model developed extends the definition given within [IPO-IMP] 187 and [IPO-FRAME] by enabling �fiber topology� non-limited to point- 188 to-point node connections. Physical resources considered within this 189 model are a common denominator of most Optical Transport Network 190 (OTN) environments. 192 As represented in Figure 1, the fiber trunk from the location N1 to 193 the location N3 is composed by the fiber segments A and B and the 194 fiber trunk from the location N1 to the location N2 includes the 195 fiber segment A, C and D. 197 Location N1 Location N3 199 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 200 --------------------------------------------------------------- 201 === . . . ====== Fiber Fiber ====== . . ==== 202 === . . . ====== Fiber Fiber ====== . . . ==== 203 -------------------------------------------------------------- 204 Sub-Segment A[1] Sub-Segment B[1] 205 ------------------------------ ----------------------------- 206 === . . . ====== Fiber | | Fiber ====== . . . ==== 207 === . . . ====== Fiber | | Fiber ====== . . . ==== 208 ------------------------- | | ------------------------- 209 +++++++++++++++++++++++++ | | | | +++++++++++++++++++++++++ 210 Segment A + | | | | + Segment B 211 + | | | | + 212 + | | | | + 214 D.Papadimitriou et al. � Internet Draft - Expires May 2002 4 215 + | | | | + Segment C 216 + | | | | + 217 + | | | | + 218 Segment D + | | | | + Segment E 219 +++++++++++++++++++++++++ | | | | +++++++++++++++++++++++++ 220 ------------------------- | | ------------------------- 221 === . . . ====== Fiber | | Fiber ====== . . . ==== 222 === . . . ====== Fiber | | Fiber ====== . . . ==== 223 ------------------------------ ------------------------------ 224 Sub-Segment D[1] Sub-Segment E[1] 225 --------------------------------------------------------------- 226 === . . . ====== Fiber Fiber ====== . . . ==== 227 === . . . ====== Fiber Fiber ====== . . . ==== 228 --------------------------------------------------------------- 229 Sub-Segment D[n] Sub-Segment E[n] 230 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 232 Location N2 Location N4 234 Figure 1. An example for the physical topology 236 In this figure, the Segment A is composed by the fiber sub-segments 237 A[1], A[2], ..., A[I], ..., A[n]. The same terminology applies for 238 the segments B, C, D and E. 240 Consequently, the fiber trunk from location N2 to location N4 241 includes the sub-segments D[2] to D[n] and their corresponding sub- 242 segments within the segment E: E[2] to E[n]. The fiber trunk from 243 location N1 to location N2 includes the fiber sub-segments A[n], 244 C[1] and D[1]. 246 3.2 Geographical Hierarchy (or Logical Hierarchy) 248 Concerning the geographical hierarchy, the SRLG model developed in 249 this document, includes the following definitions going from the 250 less to the most extended logical structure partitioning of the area 251 covered by the optical network (as shown in Figure 2.) 253 - Node: a node is a single device or active element included within 254 the optical network; a node could be an Optical Cross-Connect 255 (OXC) or a Photonic Cross-Connect (PXC). Exit points of a node are 256 defined as the node ports. 258 - Zone: a zone includes one or more nodes whose location is limited 259 to a confined area for the sake of maintainability. Zones have a 260 fixed number of exit points and are non-overlapping meaning that a 261 given node belongs to only one zone. 263 - Region: a region includes one or more zones whose location covers 264 the individual locations of each of the area composing this 265 region. Regions have a fixed number of exit points and are non- 266 overlapping meaning that a given zone belongs to only one region. 268 D.Papadimitriou et al. � Internet Draft - Expires May 2002 5 269 Hence, a region could include one or more than one non-overlapping 270 zone each of these zones could include one or generally more than 271 one node. 273 +---------------------------------------------------------------+ 274 | Region 2 | 275 | +--------------------------+ +---------------------------+ | 276 | | | | Zone 2 | | 277 | | | | +----------+ +----------+ | | 278 | | | | | | | A----B | | | 279 | | Region 1 | | | Zone 1 | | | | | | | 280 | | | | | | | C----D | | | 281 | | | | +----------+ +----------+ | | 282 | | | | | | 283 | +--------------------------+ +---------------------------+ | 284 | | 285 | +---------------------------+ | 286 | | | | 287 | | +----------+ +----------+ | | 288 | | | | | | | | 289 | | | Zone 3 | | Zone 4 | | | 290 | | | | | | | | 291 | | +----------+ +----------+ | | 292 | | Region 3 | | 293 | +---------------------------+ | 294 | | 295 +---------------------------------------------------------------+ 297 Figure 2. An example for the logical topology 299 Note: A zone could correspond to an IGP area such as an OSPF area, 300 and a region to an OSPF Autonomous System (or BGP Autonomous 301 Systems). However, the model does not exclude network topologies 302 where the SRLG geographical hierarchy does not map the routing 303 hierarchical topology. 305 3.4 SRLG Definition and Properties 307 A SRLG is defined as the set of links or optical lines sharing a 308 common physical resource (including fiber links/sub-segment/ 309 segment/trunk) i.e. sharing a common risk. For instance, a set of 310 links L belongs to the same SRLG S, if established over the same 311 fiber link F. 313 3.4.1 SRLG Properties 315 The SRLG properties can be summarized as follows: 317 1) A link belong to more than one SRLG if and only if it crosses one 318 of the resources covered by each of these sets 320 D.Papadimitriou et al. � Internet Draft - Expires May 2002 6 321 For instance: link l belongs to the SRLG s1 and s2, if it crosses 322 the fiber sub-segment A[1] and B[1] 324 2) Two links belonging to the same SRLG can belong individually to 325 other (one or more) SRLGs 327 For instance: link l1 and link l2 belongs to SRLG s3 (segment A) 328 while l1 belongs to SRLG s1 (since covering sub-segment A[1]) and l2 329 to SRLG s4 (since covering sub-segment D[1]) 331 3.4.2 LSP SRLG Disjointess 333 The LSP SRLG disjointness concept is based on the following 334 postulate: an LSP (i.e. sequence of links) cover an SRLG if and only 335 if it crosses one of the links belonging to that SRLG. For instance: 336 LSP p1 covering SRLG s1 (since including link l1) 338 Therefore, the LSP SRLG disjointness can be defined as follows: two 339 LSPs are disjoint with respect to an SRLG s1 if and only if none of 340 them covers simultaneously this SRLG. For instance: LSPs p1 and p2 341 are disjoint with respect to SRLG s1 since only p1 covers SRLG s1 343 While the LSP SRLG (set) disjointness is defined when two lightpaths 344 are disjoint with respect to a set of SRLGs S if and only if the 345 sets of SRLGs they cover are completely disjoint. For instance: LSP 346 p1 and p3 are disjoint with respect to set of SRLG S = {s1, s2, s3} 347 since only p1 covers SRLG set S. 349 3.5 SRLG Computational Model 351 This section briefly describes the guidelines for an SRLG 352 Computational Model based on the above definition. The main features 353 of this model are: 355 - Support Constraint-based Shortest Path First (CSPF) algorithm for 356 lightpath explicit route (or path) computation by considering 357 physical SRLG disjointness with respect to one (or more than one) 358 risk type 360 - Encompass hierarchical dependencies between physical resources 361 (inference of SRLG sets using bottom-up relational computation) 363 - CSPF computation including the relationship between physical 364 resources and topological structures. For instance: 365 - a fiber link can be part of �trunk� included in a specific 366 geographical region (Paris, Channel, etc.) 367 - a fiber cable passing through �earthquake� region like Japan or 368 California 370 - Provide Risk assessment during path computation implying 371 allocation of conditional failure probabilities with SRLGs 373 D.Papadimitriou et al. � Internet Draft - Expires May 2002 7 374 - SRLG information flooding well-scoped to reduce the amount of 375 link-state advertisements by using summarization 377 Consequently, the above features suggest an SRLG encoding mechanism 378 that enables: 379 - Accommodation of the resources covered by physical and topological 380 hierarchies 381 - Reduction of the optical channel path (explicit route) 382 computational complexity 384 3.6 Hierarchical SRLG encoding 386 Using the above definitions and properties, the objective of the 387 hierarchical encoding is to achieve aggregation (i.e. summarization) 388 of the SRLG Identifiers at the boundary of geographical structures 389 defined logically on top of the optical network topology. For this 390 purpose, we propose a linear encoding scheme including a type field. 391 This provides abstraction of the physical layer structure and should 392 facilitate the management of the SRLG Identifiers. 394 Consequently, the detailed encoding of an SRLG includes: 396 1. SRLG Location (32-bit field) 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Region ID | Zone ID | Reserved (16-bit) | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 The SRLG Location field identifies the logical structure into which 405 the common resource(s) defining the SRLG are included. For 406 simplicity, we say that the SRLG Location field identifies the 407 location of the SRLG. 409 The Location field includes the Region ID (8-bit) which identifies a 410 Region and the Zone ID (8-bit) identifying a Zone belonging to this 411 Region. 413 2. SRLG Identifier (32-bit field) 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Type | Identifier | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Within the SRLG Identifier, the Type field defines the resource type 422 (i.e. the �link� type) to which the Identifier defined as a 24-bit 423 integer value. The following resource types (i.e. �link� type) are 424 currently defined: 426 Type Value 428 D.Papadimitriou et al. � Internet Draft - Expires May 2002 8 429 ----------------- ----- 430 Reserved 0x00 431 Fiber Trunk 0x01 432 Fiber Segment 0x02 433 Fiber Sub-segment 0x03 434 Fiber Link 0x04 436 Logical resources such as optical channels and TDM circuits (or 437 optical sub-channels) can be also defined as described in Section 3: 439 Type Value 440 ------------------- ----- 441 Optical Channel 0x05 442 Optical Sub-Channel 0x06 444 Since a given resource (for instance a fiber link) can belong to 445 more than one SRLG, the SRLG Identifier structure is defined in the 446 most general case as a list of SRLG Identifier (n x 32-bit): 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Type | Identifier | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Type | Identifier | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | | 456 // ... // 457 | | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Type | Identifier | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Therefore, though we propose a linear encoding, the summarization of 463 the SRLG (at the logical structure boundaries) is still possible 464 since the SRLG identifiers are structured as follows: 465 - An SRLG Location field (32 bits): Region (8 bits) + Zone (8 466 bits) + Unspecified (16 bits) 467 - An SRLG Identifier field (32 bits): Type (8 bits) + 468 Identifier (24 bits) 470 This encoding enables one to perform summarization at the boundaries 471 of logical structures defining the spatial coverage of an SRLG 472 Identifier List while overcoming the drawbacks of full hierarchical 473 encoding scheme. 475 Note: the proposed encoding does not include the conditional failure 476 probability as defined in section 4.2 478 4. Risk Assessment 480 Risk assessment is defined as the quantification process of the 481 potential risk associated to the inclusion of a given resource (this 483 D.Papadimitriou et al. � Internet Draft - Expires May 2002 9 484 resource belongs to a given resource type located within a given 485 logical structure such as a geographical location) in a given 486 optical channel. 488 4.1 Rationale for Risk Assessment 490 Consider the following example, where the client device makes the 491 following connection requests to the optical network: 493 - Request for a persistent connection with 99.999 % (well known 5 494 9s) of availability or equally a down time less than X minutes per 495 year. 497 - Request a high-protection for a portion of the traffic (at the 498 expense of more charging) compared to other low-priority traffic. 500 Such requirements will be translated into path specific request. 501 Such path specific request can be grouped into path selection 502 requirements and path characterization requirements. 504 1. Path selection requirements 506 These typically dictate which physical path should be taken to 507 achieve the availability requirements of the client. These 508 requirements are typically the logical and physical diversity as 509 mentioned in the hierarchical encoding section (see section 3). 511 2. Path characterization requirements 513 Path characterization requirements typically dictate the protection 514 mechanisms as specified by the client connection request. This can 515 be achieved in the form of optical ringed protection, meshed 516 protection mechanisms, or combination of both linear and ringed 517 protection. However, these are out of the scope of this document. 519 The components that need formalization in this example are: 520 - Step 1. Specification of the user requirements (such as the 521 example above) 522 - Step 2. Configuring the network that helps in assessing the 523 features such as the availability 524 - Step 3. Propagating the above-configured information. 525 - Step 4. Using the above-propagated information. 527 Step 1 of specifying the requirements is not in the scope of this 528 document. Steps 2 to 4 are discussed in the remainder of this 529 document. 531 As an example for this discussion we elaborate on the risk 532 assessment for a selected path. 534 4.2 Quantifying the Risk Assessment 536 D.Papadimitriou et al. � Internet Draft - Expires May 2002 10 537 Risk (the complementary of availability) assessment is defined as 538 the evaluation of the potential risk associated to the inclusion of 539 a specific resource (this resource belongs to a given resource type 540 located within a given logical structure such as a geographical 541 location) in a given path. 543 Given that an SRLG Identifier list is used to encode the group of 544 logical or physical resources, if a mechanism is devised to assign 545 the risk associated with the corresponding resource, we can 546 calculate the availability of the corresponding path. This, in order 547 to meet the connection availability as requested by the client. 549 A simple approach is to assign the conditional failure probability 550 with each of the SRLG Identifier. This information can be encoded as 551 an optional parameter along with the SRLG information as defined in 552 Section 3.3. In addition, weights can be associated to each of the 553 SRLG to either increase or decrease the potential usage of the 554 resource (i.e. inclusion into the selected route). 556 In this approach the configurable parameters are: 557 - SRLG Resource and SRLG Location Identifiers 558 - Conditional failure probability per SRLG 559 - Weight for the selection of the SRLG 561 As mentioned above, the resource failure probability is defined as a 562 conditional probability. For instance, we can associate a 563 conditional failure probability of 25% to any fiber sub-segment 564 located within the same zone. It means that by selecting two (or 565 more than two) different optical channel routes including the same 566 SRLG identifier with respect to fiber sub-segment failure, if one of 567 these lightpaths fails, then the probability that the other 568 lightpath fails is 25%. 570 Moreover, the failure probability of a fiber can also depend on the 571 zone into which the fiber is located as well as the length of the 572 fiber. In addition, a fiber can pass across different zones with 573 different failure probabilities. In this case, we need to consider 574 an aggregated failure probability per fiber taking into account each 575 of the failure probability of the sub-components. 577 For instance, if we refer to our previous example and by considering 578 that: 579 1. a conditional failure probability of 50% is associated to any 580 fiber link 581 2. a conditional failure probability of 1% to any fiber segment 582 located within the same zone 584 Then by selecting two different optical channels included within the 585 same SRLG with respect to fiber segment failure (S1, for instance), 586 we obtain a simultaneous lightpath failure probability of 1%. 587 Consequently, if the client asks for a protected path, by choosing 588 fiber segment path disjointness, the simultaneous lightpath failure 589 probability is also of 1%. However, choose two optical channels 591 D.Papadimitriou et al. � Internet Draft - Expires May 2002 11 592 flowing through the same fiber (r1, for instance), then we have a 593 probability of 50% that both optical channels fail simultaneously. 595 4.3 Risk Assessment Application 597 Up to now we didn�t define the association between the high 598 availability of the path and SRLG conditional failure probability. A 599 simple way to define the relationship is to consider the 600 availability of the service requested by the client (i.e. a working 601 and a protected path from the provider point of view) and 602 conditional failure probability of the sequence of physical resource 603 elements included within the corresponding paths. So if we consider, 604 1. a path whose source is located is zone 1 and whose destination in 605 zone 2 (same region) 606 2. a conditional failure probability of 1% if fiber links are 607 selected within the same fiber trunk (and located within the zone 608 1) 609 3. a conditional failure probability of 1% if fiber links are 610 selected within the same fiber trunk (and located within the zone 611 2) 612 4. the conditional failure probabilities are independent and 613 weighted equally 615 Then, the availability of the service concerning the fiber link 616 availability is of 98% since in this specific case conditional 617 failure probabilities are additive. 619 Note that currently, the initial conditional failure probability 620 value need to be statically encoded; however, based on the �history� 621 of the failures these values could be dynamically re-evaluated. The 622 corresponding mechanism still needs to be specified and left for 623 further study. 625 5. SRLG Inference Model Application 627 The SRLG Inference Model applications are related to the CSPF 628 lightpath route computation and the SRLG identifier sets 629 summarization in order to enable intra- and inter-area diverse 630 routing. For that purpose we first extend the SRLG concept for 631 logical resources such as optical channels and optical sub-channels 632 (i.e. TDM circuits). 634 5.1 Extension of the SRLG Concept to Logical Structures and Resources 636 The SRLG concept can be extended to logical-level structures and 637 resources by taking into account the following purposes: 639 1. Given the physical and geographical-level decomposition of the 640 optical network topology, the SRLG encoding can be hierarchically 641 structured. The hierarchical encoding helps in constructing the 642 logical-level topological abstraction, which in turn can be used 643 in the SRLG summarization and loose-path computation. The link 644 semantics could be also extended to accommodate the inter-region 646 D.Papadimitriou et al. � Internet Draft - Expires May 2002 12 647 and inter-zonal links. 649 2. Propagate these additional logical-level (structures and 650 resources) links using the IGP routing protocols for intra- and 651 inter-area routing purposes. 653 3. To reduce the amount of the flooded information and hence 654 lightpath route computation complexity, the flooding scope of the 655 information propagation is extended to accommodate logical 656 structures (i.e. region and zone) and logical resources (i.e. 657 optical channels and TDM circuits). 659 5.2 Propagation SRLG Information 661 The SRLG of each link (i.e. physical and logical resources) is 662 encoded as described in Section 3.3, and this information is 663 propagated once at configuration between the various nodes using the 664 traffic engineering extensions to the IGP routing protocols such as 665 OSPF [GMPLS-OSPF] and IS-IS [GMPLS-ISIS]. After this initial SRLG 666 identifier exchange, corresponding values do not change over the 667 time. 669 This propagation of SRLG information will be necessary whenever a 670 new link is added or an existing link is removed. Initially the 671 probability of failure of the various resources are assumed to be 672 configured; it is envisioned that at some later time, the 673 probability of failure of the SRLG will be propagated along with the 674 SRLG itself (as described in Section 3.3). 676 5.3 Bottom-Up Computation of the SRR Relations 678 Once the traffic-engineering topological information is received by 679 the node, the Shared Risk Relationship (SRR) graph can be calculated 680 on a regular basis, using the bottom up method described in [SRLG- 681 RTG]. The fiber trunk SRR is used to compute the fiber segment SRR, 682 which in turn is then used to compute the fiber sub-segment SRR 683 until the fiber SRR computation is achieved. To the SRR which 684 defines the membership of a resource belonging to the same SRLG set, 685 we associate at each resource level (for instance, with this fiber 686 SRR), the conditional failure probability between two elements 687 belonging to this level (for instance, between two fibers). 689 5.4 Summarization in Topology and Resource Distribution 691 By combining recursively several dependency graphs of known 692 structures into a higher-level dependency graph, the number of SRLG 693 sets and the number of element they include can be further reduced 694 (i.e. the SRLG identifier information is aggregated). Consequently, 695 the applications of the extended model will also cover the reduction 696 of the SRLG advertisements in the Topology and Resource Distribution 697 running instance (i.e. the traffic engineering extensions to the 698 link-state advertisements of the IGP protocol). In turn, this 700 D.Papadimitriou et al. � Internet Draft - Expires May 2002 13 701 improvement will reduce the CSPF algorithm complexity for optical 702 channel path calculation (i.e. engineered lightpath setup). 704 5.5 CSPF Route Computation 706 Applications of this model are directly related to the Constraint- 707 based Shortest Path First (CSPF) algorithm used for lightpath route 708 computation (i.e. traffic-engineered lightpath creation) to maximize 709 the lightpath disjointness and so decrease their common failure 710 probability. Given an existing set of lightpaths across the network, 711 the objective is thus to compute a route across the optical network 712 topology for a newly requested lightpath such that this lightpath is 713 diversely routed from a given set of existing lightpaths. 715 The diversity requirement is a routing constraint, and is expressed 716 as the conditional failure probability of a requested lightpath with 717 respect to the failure of an existing (set of) lightpath. Hence, in 718 addition to the other traffic-engineering constraints, the diversity 719 constraint requires that the conditional failure probability not 720 exceed a given threshold. Therefore, the CSPF algorithm needs to be 721 updated to take the routing diversity constraint into account. 723 Moreover, the SRLG concept generates another dimension to the 724 existing constraint-based path computation methods traditionally 725 used in MPLS-TE based hierarchical networks. The SRLG constraints 726 provide an additional dimension to the common traffic-engineering 727 constraints such as bandwidth availability, link metrics and other 728 parameters. The routing diversity constraint specificity requires 729 the use of more appropriate path computation algorithms that provide 730 not only complete multi-path disjointness but also partial multi- 731 path disjointness with respect to various risk factors. In a similar 732 way, appropriate mechanisms should also be used in order to perform 733 path re-optimization following various restoration strategies. 735 6. Security Considerations 737 Security considerations related to SRLG Inference model and its 738 applications are left for further study. 740 7. References 742 1. [GMPLS-OSPF] K.Kompella et al., �OSPF Extensions in Support of 743 Generalized MPLS�, Internet Draft, Work in Progress, draft-ietf- 744 ccamp-ospf-gmpls-extensions-00.txt, September 2001. 746 2. [GMPLS-ISIS] K.Kompella et al., �ISIS Extensions in Support of 747 Generalized MPLS�, Internet Draft, Work in Progress, draft-ietf- 748 isis-gmpls-extensions-04.txt, September 2001. 750 3. [IEEE-ORL] John Strand et al., �Issues for Routing in the Optical 751 Layer�, IEEE Communication Magazine, Volume 39, Number 2, February 752 2001. 754 D.Papadimitriou et al. � Internet Draft - Expires May 2002 14 755 4. [IPO-FRAME] J. Luciani et al., �IP over Optical Networks A 756 Framework�, Internet Draft, Work in progress, draft-many-ip-optical- 757 framework-03.txt, March 2001. 759 5. [IPO-IMP] J. Strand, A.Chiu et al., �Impairments And Other 760 Constraints On Optical Layer Routing�, Internet Draft, Work in 761 progress, draft-ietf-ipo-impairments-00.txt, May 2001. 763 6. [MPLS-BUNDLE] K.Kompella et al., �Link Bundling in MPLS Traffic 764 Engineering�, Internet Draft, Work in progress, draft-kompella-mpls- 765 bundle-05.txt, March 2001. 767 7. [SRLG-RTG] F.Poppe et al., �SRLG and Routing�, Paper under 768 revision. 770 8. Acknowledgments 772 The authors would like to thank Bernard Sales, Emmanuel Desmet, Hans 773 De Neve, Fabrice Poppe and Gert Grammel for their constructive 774 comments and input. 776 9. Author's Addresses 778 Dimitri Papadimitriou (Editor) 779 Alcatel 780 Francis Wellesplein, 1 781 B-2018 Antwerpen, Belgium 782 Phone: +32 3 240-8491 783 Email: dimitri.papadimitriou@alcatel.be 785 Fabrice Poppe 786 Alcatel 787 Francis Wellesplein, 1 788 B-2018 Antwerpen, Belgium 789 Phone: +32 3 240-8006 790 Email: fabrice.poppe@alcatel.be 792 Jim Jones 793 Alcatel 794 3400 W. Plano Parkway, 795 Plano, TX 75075, USA 796 Phone: +1 972 519-2744 797 Email: jim.d.jones1@usa.alcatel.com 799 Senthil Venkatachalam 800 Alcatel 801 45195 Business Court, Suite 400 802 Dulles, VA 20166, USA 803 Phone: +1 703 654-8635 804 Email: senthil.venkatachalam@usa.alcatel.com 806 Sudheer Dharanikota 808 D.Papadimitriou et al. � Internet Draft - Expires May 2002 15 809 Nayna Networks 810 157 Topaz St., 811 Milpitas, CA 95035, USA 812 Phone: +1 408 956-8000X357 813 Email: sudheer@nayna.com 815 Raj Jain 816 Nayna Networks 817 157 Topaz St., 818 Milpitas, CA 95035, USA 819 Phone: +1 408 956-8000X309 820 Email: raj@nayna.com 822 David W. Griffith 823 National Institute of Standards and Technology (NIST) 824 100 Bureau Drive, Stop 8920 825 Gaithersburg, MD 20899-8920, USA 826 Phone: +1 301 975-3512 827 Email: david.griffith@nist.gov 829 Riad Hartani 830 Caspian Networks 831 170 Baytech Drive, 832 San Jose, CA 95134, USA 833 Phone: +1 408 382-5216 834 Email: riad@caspiannetworks.com 836 Yong Xue 837 UUNET/WorldCom 838 Ashburn, VA, USA 839 Phone: +1 703 886-5358 840 Email: yxue@uu.net 842 D.Papadimitriou et al. � Internet Draft - Expires May 2002 16 843 Full Copyright Statement 845 "Copyright (C) The Internet Society (date). All Rights Reserved. 846 This document and translations of it may be copied and furnished to 847 others, and derivative works that comment on or otherwise explain it 848 or assist in its implementation may be prepared, copied, published 849 and distributed, in whole or in part, without restriction of any 850 kind, provided that the above copyright notice and this paragraph 851 are included on all such copies and derivative works. However, this 852 document itself may not be modified in any way, such as by removing 853 the copyright notice or references to the Internet Society or other 854 Internet organizations, except as needed for the purpose of 855 developing Internet standards in which case the procedures for 856 copyrights defined in the Internet Standards process must be 857 followed, or as required to translate it into languages other than 858 English. 860 The limited permissions granted above are perpetual and will not be 861 revoked by the Internet Society or its successors or assigns. 863 This document and the information contained herein is provided on an 864 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 865 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 866 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 867 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 868 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 870 D.Papadimitriou et al. � Internet Draft - Expires May 2002 17