idnits 2.17.1 draft-papadimitriou-optical-rings-02.txt: -(1239): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1245): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1247): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1253): 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 14 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2281 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. 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) -- Looks like a reference, but probably isn't: '1' on line 1400 == Missing Reference: 'IPO-RFR' is mentioned on line 58, but not defined == Missing Reference: 'OPT-NET' is mentioned on line 382, but not defined == Missing Reference: 'ITUT-G841' is mentioned on line 286, but not defined == Missing Reference: 'GMPLS-RSVPTE' is mentioned on line 364, but not defined == Missing Reference: 'N' is mentioned on line 941, but not defined == Missing Reference: 'OPT-MRPS' is mentioned on line 970, but not defined == Missing Reference: 'ITUT-G872' is mentioned on line 1027, but not defined == Missing Reference: 'ITUT-G709' is mentioned on line 1028, but not defined == Missing Reference: 'IPO-PATH' is mentioned on line 1371, but not defined -- Looks like a reference, but probably isn't: '2' on line 1400 == Missing Reference: 'OSPF-OPA' is mentioned on line 1484, but not defined == Unused Reference: 'GMPLS-ISIS' is defined on line 1809, but no explicit reference was found in the text == Unused Reference: 'GMPLS-RSVP' is defined on line 1817, but no explicit reference was found in the text == Unused Reference: 'GMPLS-BUNDLE' is defined on line 1825, but no explicit reference was found in the text == Unused Reference: 'IPO-MPLS' is defined on line 1841, but no explicit reference was found in the text == Unused Reference: 'IPO-RFRM' is defined on line 1859, but no explicit reference was found in the text == Unused Reference: 'MPLS-CRLDP' is defined on line 1878, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-gmpls-architecture-00 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-04 -- No information found for draft-kompella-isis-gmpls-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'GMPLS-ISIS' == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-ospf-gmpls-extensions-00 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-05 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-06 -- Possible downref: Normative reference to a draft: ref. 'GMPLS-BUNDLE' == Outdated reference: A later version (-01) exists of draft-guo-optical-aps-00 -- Possible downref: Normative reference to a draft: ref. 'IPO-OAPS' -- Possible downref: Normative reference to a draft: ref. 'IPO-BUNDLE' -- No information found for draft-ietf-ip-optical-framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IPO-FRAME' -- Possible downref: Normative reference to a draft: ref. 'IPO-MPLS' -- Possible downref: Normative reference to a draft: ref. 'IPO-MULT' == Outdated reference: A later version (-02) exists of draft-pbh-packet-optical-escalation-01 -- Possible downref: Normative reference to a draft: ref. 'IPO-POES' -- Unexpected draft version: The latest known version of draft-many-optical-restoration is -01, but you're referring to -02. (However, the state information for draft-ietf-ip-optical-framework is not up-to-date. The last update was unsuccessful) -- Possible downref: Normative reference to a draft: ref. 'IPO-REST' -- Possible downref: Normative reference to a draft: ref. 'IPO-RFRM' -- No information found for draft-guo-optical-mesh-rings - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IPO-OMR' -- Possible downref: Normative reference to a draft: ref. 'IPO-SRLG' == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-lmp-02 == Outdated reference: A later version (-03) exists of draft-fredette-lmp-wdm-02 -- Possible downref: Normative reference to a draft: ref. 'LMP-WDM' == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'OPT-MWS' -- Possible downref: Non-RFC (?) normative reference: ref. 'OPT-RINGS' == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-06 == Outdated reference: A later version (-02) exists of draft-venkatachalam-ospf-traffic-00 -- Possible downref: Normative reference to a draft: ref. 'OSPF-IRTE' ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) -- Possible downref: Non-RFC (?) normative reference: ref. 'SPT-DYN' Summary: 6 errors (**), 0 flaws (~~), 32 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPO Working Group D. Papadimitriou 3 Document: draft-papadimitriou-optical-rings-02.txt Alcatel 4 Category: Internet Draft 5 Expires: May 2002 6 November 2001 8 Optical Rings and Hybrid Mesh-Ring Optical Networks 10 draft-papadimitriou-optical-rings-02.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 except that the right to 16 produce derivative works is not granted. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Conventions used in this document: 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC-2119 [1]. 38 Abstract 40 The scope of this draft is to specify the IP-based signaled 41 protection mechanisms for optical rings and hybrid optical mesh-ring 42 topologies. With the dynamic ring configuration process, we determine 43 the information to be distributed to dynamically emulate optical 44 rings on top of a meshed optical network topology. This information 45 exchange further enables the specification of Optical Ring Traffic 46 Engineering. Within the IP Control-based signaling plane, we also 47 specify the mechanisms to provide dynamic and fast-protection 49 Papadimitriou D. - Internet Draft - Expires May 2002 1 50 switching, and distributed LSP route computation on top of ring-based 51 and hybrid mesh-rings optical networks. 53 1. Introduction 55 The concept of optical ring emulation applies when considering the 56 ring configuration on top of optical mesh topology including Optical 57 Cross-Connects (OXC) and not only Optical Add-Drop-Multiplexers (O- 58 ADM). Compared to the approach proposed in [IPO-RFR] and developed in 59 [IPO-OMR], emulated optical rings add configuration flexibility when 60 considering optical network protection. The mechanisms developed here 61 are quite general and enable the deployment of hybrid mesh-rings 62 optical network topologies. It also provides a clear separation 63 between the dynamic ring configuration and the dynamic ring resource 64 allocation. This allows a greater ring resource management 65 flexibility that fits more suitably the bandwidth on demand 66 requirements for optical networks. 68 The complexity of ring emulation arises when defining several rings 69 on top of a mesh topology including Optical Cross-Connects (OXC) 70 connected through fiber trunks. This because by configuring several 71 optical rings on top of a meshed topology, a ring cover is defined. 72 Consequently, the shared protection of some parts of ring - 73 specifically the links and the nodes - with other contiguous rings 74 implies the definition of specific as described in [OPT-NET] and 75 [OPT-RINGS]. The corresponding fast link protection mechanism is 76 performed at the node level is completely distributed and autonomous. 77 Note that it still requires signalling message exchange in order to 78 recover unidirectional link failures. 80 The approach developed here combines distributed fast link protection 81 mechanism and signalling message exchange between nodes when a 82 failure is detected on a link connecting to adjacent nodes belonging 83 to the same ring. In order to specify these mechanisms, we first 84 describe the optical ring concept currently under development at the 85 ITU-T to determine the corresponding mechanism for all-optical rings. 87 2. Optical Rings - Concepts 89 2.1 ITU-T Optical Rings 91 The aim of this section is neither to describe the pro and cons of 92 optical rings with respect to optical mesh network nor to explain in 93 detail the well known ITU-T ring technology [ITUT-G841]. Many 94 references can be found comparing, the architecture, the protection 95 as well as the resource use of both kinds of topologies. 97 The objective is to determine the requirements and the functional 98 aspects of these ring technologies in order to define the 99 corresponding mechanisms for all-optical rings. For that purpose, we 100 first describe the ring technology and types of protected rings 101 currently defined (by using ITU-T terminology): 103 Papadimitriou D. - Internet Draft - Expires May 2002 2 104 - Optical Channel Dedicated Protection Ring (OCh-DPRing) or O-UPSR 105 (Optical Unidirectional Path Switched Ring). Dedicated protection 106 can also be provided through Single Optical Channel (1+1) Sub- 107 network Connection Protection (OCh-SNCP). 109 - Optical Channel Shared Protection Ring (OCh-SPRing) or O-BPSR 110 (Optical Bi-directional Path Switched Ring) existing in two 111 flavors: 2 Fiber O-BPSR (O-BPSR/2) and 4-Fiber O-BPSR (O-BPSR/4) 112 and 2 switching strategies: ring switch (2- and 4-Fiber) and span 113 switch (4-Fiber only). 115 - Optical Multiplex-Section Dedicated Protection Ring (OMS-DPRing) or 116 O-ULSR (Optical Unidirectional Line Switched Ring) 118 - Optical Multiplex-Section Shared Protection Ring (OMS-SPRing) or O- 119 BLSR (Optical Bi-directional Line Switched Ring) existing in 2 120 flavors: 2 Fiber O-BLSR (O-BLSR/2) and 4-Fiber O-BLSR (O-BLSR/4) 121 and 2 switching strategies: ring switch and span switch. 123 Details about the corresponding SDH ring architectures can be found 124 in ITU-T G.841 (for SDH/Sonet networks). The ITU-T is currently 125 defining Optical Transport Network (OTN) Ring Architecture by 126 extending the G.841 specification. 128 These ring types can be treated separately if we differentiate the 129 unidirectional (OMS and OCh) Dedicated Protection Rings (DPRing) from 130 the bi-directional (OMS and OCh) Shared Protection Rings (SPRing). 131 This by taking into account that switched rings are also referred to 132 as self-healing rings (SHR) since they protect automatically against 133 failures. The main feature of self-healing rings is their ability to 134 recover any LSP in case of link (i.e. fiber) failure and part of the 135 LSP in case of node failure. 137 SHR applied on optical rings are referred to as WDM-SHR. The 138 corresponding protection mechanism are briefly described here: 140 1. OMS-DPRing (or O-ULSR): 141 - Unidirectional OMS protection is achieved by using 1+1 fast 142 protection switching at the OMS-layer. 143 - One fiber is dedicated as working fiber and the other is 144 dedicated as protection fiber. Working and protection fibers 145 operate in opposite directions: the working ring operates on 146 the clockwise direction on the protection ring on the counter 147 clockwise direction. The protection ring carries the same 148 signal than the working fiber but in the opposite direction. 149 The same mechanism applies if we replace the term fiber by 150 wavelength. 151 - Since single-ended protection (or unidirectional protection 152 switching) is used, OMS-DPRing does not require coordinated 153 O-APS signalling at the OMS-layer. 155 Papadimitriou D. - Internet Draft - Expires May 2002 3 156 2. OMS-SPRing (or O-BLSR): 157 - OMS switched rings are based on optical automatic protection 158 switching (O-APS) protocol through signalling channel by using 159 OMS overhead bytes (or equivalent). The O-APS mechanism 160 enables coordinated actions at the OMS-layer between nodes 161 when a failure occurs. 162 - OMS-SPRing performs bulk OCh-layer switching based on OMS- 163 level failure indications through OMS-layer O-APS signaling; 164 all optical-channels are protected (i.e. switched) as a group 165 within the OMS (so incapable of protecting optical channels 166 independently of one another based on OCh-layer failure 167 indications. 168 - Ring switching protection (2-fiber and 4-fiber) is based on 169 loopback protection switching and activated when both working 170 and protection link failure occurs simultaneously. By using O- 171 APS signalling, when a link failure occurs, the working lines 172 (wavelength) from the working fiber are looped back onto the 173 opposite direction on protection wavelength on the protection 174 fiber in the opposite direction. Note that combination of 175 working and protection link failure and node failure should 176 also be considered. 177 - Span switching protection (4-fiber only) is activated when 178 only working link failure occurs. When a link failure occurs, 179 the working lines (wavelengths) from the working fiber are 180 switched to the protection fiber in the same direction. Span 181 switching protection is also referred to as non-loopback 182 switched protection. 183 - In terms of SHR, OMS-SPRings are referred to as Shared Line 184 switched WDM-SHR (SLs-WDM-SHR) since they rely on shared line 185 switched protection. 187 3. OCh-DPRing (or O-UPSR) 188 - Unidirectional path switched-protection is achieved by using 189 1+1 fast protection switching at the OCh-layer. 190 - One fiber is dedicated as working fiber and the other is 191 dedicated as protection fiber. Working and protection fibers 192 operate in opposite directions: the working ring operates on 193 the clockwise direction on the protection ring on the counter 194 clockwise direction. The protection ring carries the same 195 signal than the working fiber but in the opposite direction so 196 that the protection ring fully protects the working ring. 197 The mechanism applies if we replace the term fiber by 198 wavelength. 199 - Since single-ended protection (or unidirectional protection 200 switching) is used, OCh-DPRing does not require coordinated O- 201 APS OCh-layer signalling. If a working OCh failure occurs, 202 only one direction is affected and for that direction OCh 203 switching is performed at the far-end. In the other direction, 204 no OCh-layer switching is performed. 205 - OCh-layer protection is based on optical channel resilient 206 schemes by protecting individual path; so this protection 207 allows a selective recovery of the OMS between nodes 209 Papadimitriou D. - Internet Draft - Expires May 2002 4 210 - In terms of SHR, OCh-DPRings are referred to as Dedicated 211 Path switched WDM-SHR (DPs-WDM-SHR) since they rely on 212 dedicated path switched protection. 214 4. OCh-SPRing (or O-BPSR) 215 - Bi-directional path switched protection requires the need for 216 a protection architecture performing OCh switching based on 217 independent OCh failure detection. 218 - This implies the specification of an O-APS signalling 219 protocol at the OCh-layer using the OCh overhead byte. 220 - Ring switching protection can also be defined for 2- and 4- 221 Fiber OCh-SPRings. Span switching protection can be defined 222 for 4-Fiber OCh-SPRings. 223 - In terms of SHR, OCh-SPRings are referred to as Shared Path 224 switched WDM-SHR (SPs-WDM-SHR) since they rely on shared path 225 switched protection 227 The distinction between Working and Protected path is defined as 228 follows: 229 - Working path: carrying optical channel defined between the source 230 and the destination node 231 - Protecting path: non-carrying optical channel defined between the 232 source and the destination node transported over the complement of 233 the ring 235 The distinction between Working and Protected line is defined as 236 follows: 237 - Working line: carrying OMS defined between the source and an 238 intermediate node or between intermediate nodes or between an 239 intermediate node and the destination node transported over the 240 complement of the ring 241 - Protection line: non-carrying OMS defined between the source and an 242 intermediate node or between intermediate nodes or between an 243 intermediate node and the destination node transported over the 244 complement of the ring 246 The following table gives the equivalence between the linear (mesh 247 networks) and ring protection. 249 -------------------------------------------------------------------- 250 Linear Protection Ring Protection 251 -------------------------------------------------------------------- 252 Dedicated Line Protection 1+1 OMS-DPRing (O-ULSR) 253 Shared Line Protection 1:1 - 1:N - M:N OMS-SPRing (O-BLSR) 254 Dedicated Path Protection 1+1 OCh-DPRing (O-UPSR) 255 Shared Path Protection 1:1 - 1:N - M:N OCh-SPRing (O-BPSR) 256 -------------------------------------------------------------------- 258 2.3 Transparent and All-Optical Rings 260 The previous section detailed the ring technologies and types for 261 Optical Transport Networks (i.e. ITU-T G.709 based OTN). The 263 Papadimitriou D. - Internet Draft - Expires May 2002 5 264 objective here is to define the same kind of mechanisms for pure 265 optical rings. 267 A pure optical ring is defined as a ring including Optical Cross- 268 Connects (OXC) and Photonic Cross-Connects (PXC). The difference 269 between OXC and PXC is that O/E/O conversion is performed at each of 270 its interface while PXCs do not perform O/E/O conversion at all. 272 An all-optical ring is defined as ring including only PXC while a 273 transparent ring is defined as including at least one OXC. In order 274 to be independent of physical layer concerns like chromatic 275 dispersion, PMD (affecting the edge-to-edge distance), OSNR 276 (affecting the number of optical spans), crosstalk, etc., only 277 transparent optical rings are considered in the remaining parts of 278 this document. We refer to these transparent optical rings as optical 279 rings. 281 The fundamental problem of optical rings is to determine to which 282 extend the IP control-based signaling plane need to be considered for 283 defining ring protection mechanism. In the model developed in this 284 memo, we try to extract the relevant information needed in order to 285 provide the same level of resiliency as the one currently available 286 with SDH/Sonet DXC-based rings [ITUT-G841] and the corresponding 287 extension under definition for Optical Transport Networks (OTN). This 288 implies the definition at IP control-plane level of the required O- 289 APS signalling protocol by keeping independence from the current 290 protection mechanisms defined for SDH/Sonet rings. 292 The information needed to dynamically configure an optical ring on 293 top of a mesh optical network topology and the corresponding link 294 (and wavelengths) resources management information depends on: 295 - the ring identification 296 - the ring protection type 297 - the ring directionality 298 - the ring architecture 300 Based on this information, the dynamic ring configuration is 301 performed (cf. Section 3). When the optical ring has been configured 302 (i.e. emulated on top of the mesh topology), the ring resources 303 allocation to the Lambda-switched LSPs (i.e. the optical channels) 304 segments or tunnels can be computed for this emulated ring. 306 The equivalence between ITU-T rings and the corresponding protection 307 mechanism in all-optical networks is summarized in the following 308 table: 310 --------------------------------------------------------- 311 ITU-T Rings | Corresponding protection mechanism 312 --------------------------------------------------------- 313 OMS-DPRing | 1+1 dedicated fiber link (or wavelength) 314 --------------------------------------------------------- 316 Papadimitriou D. - Internet Draft - Expires May 2002 6 317 OMS-SPRing | M:N shared fiber link (or wavelength) 318 --------------------------------------------------------- 319 OCh-DPRing | 1+1 dedicated LSP segment protection 320 --------------------------------------------------------- 321 OCh-SPRing | M:N shared LSP segment protection 322 --------------------------------------------------------- 324 The OMS-layer protection (dedicated or shared) concept corresponds to 325 the protection of a wavelength bundle transported on a fiber link 326 between two adjacent nodes. The OCh-layer protection (dedicated or 327 shared) concept corresponds to the protection of LSP segment(s) 328 transported on a wavelength switched path (i.e. partial LSP path) 329 between the ingress and the egress node of a given ring. 331 Knowing each of the SDH/Sonet and OTN ring functional aspects and the 332 mapping of the underlying concepts with their counterparts in all- 333 optical networks, the corresponding ring protection mechanism can be 334 defined. 336 2.3 Meshed Optical Network Topology 338 The basic assumptions concerning the optical network topology are to 339 be considered within the scope of [GMPLS-ARCH]: 341 - Mesh (and transparent) optical network including Optical Cross- 342 Connect (OXC) connected through fiber trunks as described in [IPO- 343 SRLG]. 345 - OXC interfaces or ports are Lambda-Switch Capable (LSC) interfaces 346 as described in [GMPLS-SIG] meaning that any OXC interface includes 347 DWDM capabilities. OXC or eventually fiber switch capable (FSC) 348 interfaces (but they are considered as a particular outside the 349 main scope of this document). 351 - Each of these OXCs has its own IP controller that may be or not 352 included within the same device. Each controller is uniquely 353 identified by its IP Address. The inter-connection of the IP 354 controllers defines the IP based control-plane of the optical 355 network. 357 - Signaling channels between the IP-based controllers of OXCs is 358 realized through either dedicated Optical Signalling Channels (out- 359 of-band/in-fiber) or through a dedicated out-of-band/out-of-fiber 360 network. 362 - Signaling protocol is based on Generalized MPLS signaling as 363 described in [GMPLS-SIG] in combination with Generalized RSVP-TE 364 [GMPLS-RSVPTE] and Generalized CR-LDP [GMPLS-CRLDP] extensions. 366 The basic meshed topology of the optical network can be represented 367 as a planar graph: 369 Papadimitriou D. - Internet Draft - Expires May 2002 7 370 A ------ B ------ C 371 | | | 372 | | | 373 | | | 374 D ------ E ------ F 375 | | | 376 | | | 377 | | | 378 G ------ H ------ I 380 Each of the nodes (vertex) of this topology is an OXC. Nodes are 381 connected through fiber links. This topology (see above figure as 382 example) also defines a planar graph [OPT-NET], G(V,E) where V is the 383 vertex and E the edge of the planar graph. The considerations 384 developed here take into account this representation of the optical 385 network topology. The non-planar case is left for further study. 387 3. Optical Ring Emulation 389 Ring emulation concept refers to the configuration of optical rings 390 on top of a meshed optical topology including OXCs and not only O- 391 ADMs. This approach provides the advantage of ring configuration 392 flexibility without having to move or replace the devices already 393 included in the optical network. 395 The emulation concept provides also more flexibility during the 396 (dynamic) configuration of optical ring covers and the resource 397 allocation between the different rings included in the cover. 399 3.1 Optical Ring Covers 401 A ring cover is defined as a set of closed paths that covers all 402 links in the optical network at least once. So, a (complete) optical 403 meshed topology ring cover of the meshed optical topology will be 404 achieved when every node can be connected to at least one ring. 406 Two types of ring covers can be defined: 407 - non-overlapping ring cover: several rings covering (any node, in 408 case of complete ring-covers) the optical network are emulated on 409 top of a mesh topology; each of these nodes belongs to only one 410 ring except boundary nodes; non-overlapping ring covers can be 411 complete (covering the whole meshed topology) or incomplete 412 (partially covering the meshed topology) 413 - overlapping ring cover (or multi-ring cover): several rings 414 covering (any node in case of complete ring-covers) are configured 415 on top of an optical meshed topology; each of these nodes can be a 416 boundary node 418 However, in the first release of this document, we only consider non- 419 overlapping incomplete or complete ring covers. This choice is 420 motivated by the complexity of the multi-ring covers as described in 422 Papadimitriou D. - Internet Draft - Expires May 2002 8 424 [OPT-MWS] and [OPT-RINGS] where double covers of non-planar graphs 425 are studied. 427 In ring covers, fiber links shared between more than one ring are 428 referred to as shared links. However, wavelengths are dynamically 429 assigned to one (and defined as dedicated protection wavelengths) or 430 more than one ring (and defined as shared protection wavelengths). 432 Consequently, the emulation of an optical ring on top of meshed 433 optical network topology requires that: 434 - the configuration of the OXC optical switching matrix included 435 within a ring is designed to provide O-ADM functions (add, drop, 436 drop-and-continue, protection switching, etc.) 437 - in a shared link, each of the wavelengths belongs (for a given time 438 period) to one and only one ring precluding the usage of the 439 dynamically assigned wavelengths by the other ring 441 In the following mesh topology, a non-overlapping ring cover is 442 defined for instance by the following set of rings: 444 - Ring 1: A-B-E-D-A 445 - Ring 2: B-C-F-E-B 446 - Ring 3: E-F-I-H-E 447 - Ring 4: D-E-H-G-D 449 In this topology: 450 - Node C is an internal node since it belongs only to Ring 2 451 - Node D is a boundary node since it belongs to Ring 1 and Ring4 453 A ------ B ------ C 454 | | | 455 | Ring 1 | Ring 2 | 456 | | | 457 D ------ E ------ F 458 | | | 459 | Ring 4 | Ring 3 | 460 | | | 461 G ------ H ------ I 463 Node E has a particular situation in this topology since this 464 boundary node belongs to the four rings simultaneously. So, if we 465 consider each ring as an abstract node, the same topology can also 466 represented as follows 468 B,E 469 R1 --------------- R2 470 | \ / | 471 | \ / | 472 | \ E / | 473 E,D| =====x===== |E,F 474 | / E \ | 475 | / \ | 477 Papadimitriou D. - Internet Draft - Expires May 2002 9 478 | / \ | 479 R4 --------------- R3 480 E,H 482 As a result, if a node N1 connected to the ring R1 requests an LSP to 483 a node N2 connected to ring R3, the shortest ringed path is the one 484 going through Node E. This shows clearly that additional information 485 is required that takes into account the working (and protection) load 486 of the ring. This load information has to be shared between the rings 487 and between the rings and the external nodes to the rings. 489 In the same topology, an overlapping ring cover is defined by the 490 following set of rings: 492 - Ring 1: A-B-C-F-E-D-A 493 - Ring 2: D-E-F-I-H-G-D 494 - Ring 3: E-F-I-H-E 496 A ------ B ------ C 497 | | | 498 | Ring 1 | 499 | | | 500 D ------ E ------ F 501 | | | 502 | Ring 2 | 503 | | Ring 3 | 504 G ------ H ------ I 506 As mentioned previously, overlapping ring covers are not considered 507 in the first release of this document. 509 3.2 Dynamic Optical Ring Configuration 511 The emulation of a ring on top of optical meshed topology is 512 determined by the exchange of the following information between OXC: 513 - each ring is defined by a Ring ID (32-bit field) 514 - each ring shares a unique Virtual IPv4 Address (32-bit field) 515 - a Loopback IPv4 Address (32-bit field) is allocated per node 516 belonging to a given ring and per ring contiguous to a given node 517 such that neighboring nodes see a given ring as a single abstract 518 node identified by its loopback IPv4 address 519 - each ring is characterized by a Ring Protection Type (8-bit field) 520 which enables to select a given protection-type when establishing a 521 LSP over that ring 522 - each ring knows the complete list of identifiers describing the 523 SRLGs to which a given link belongs. 524 - each ring owns an associated Ring Metric used to bootstrap the 525 initial ring resource allocation during the ring configuration 526 process 528 Papadimitriou D. - Internet Draft - Expires May 2002 10 529 - each ring defines a internal Ring Policy (8-bit field) including 530 ring protection strategy, the ring protection scheme, and the 531 priority/preemption support 533 Consequently, the dynamic ring configuration includes the exchange of 534 basic identification information: the Ring Identifier, the Ring 535 Protection-Type, the Ring Virtual IP Address, the Ring Metric and the 536 Ring Policy. 538 3.2.1 Ring ID 540 Each of the node belonging to a given ring is identified by a node ID 541 defined as a Loopback IPv4 Address (in the future we will include 542 IPv6 node identification). So that a specific common identifier need 543 to exchanged between nodes belonging to the same ring. 545 For this purpose, a Ring ID defined as a 32-bit integer field that 546 uniquely identifies a given ring within a given optical domain (i.e. 547 administrative authority). 549 The ring ID is exchanged between neighboring nodes until reaching a 550 loop (on top of the meshed topology) constituted by nodes having the 551 same Ring ID. The Ring ID verification process at each node is 552 straightforward and does not require additional explanations. 554 3.2.2 Virtual IP Address 556 Each node included within a given ring shares a unique virtual IPv4 557 Address with other nodes belonging to the same ring. The IPv4 address 558 is uniquely defined per optical domain (i.e. administrative 559 authority). 561 By using a Virtual IPv4 Address to address a ring, a network 562 management system can reach any node of a given ring included within 563 a complex optical ringed topology without knowing the status of the 564 ring node or the corresponding ring topology. 566 Example: 568 If we refer to the previous optical network topology (see figure), we 569 have the following IP reachability between the multi-ring cover: 570 - Ring 1 is identified by the Ring ID 1 and Virtual IP Address 1 571 - Ring 2 ... Ring ID 2 and Virtual IP Address 2 572 - Ring 3 ... Ring ID 3 and Virtual IP Address 3 573 - Ring 4 ... Ring ID 4 and Virtual IP Address 4 575 3.2.3 Loopback IPv4 Address 577 In order to avoid the use of interface address and so potentially 578 experience disrupted communication between nodes belonging to the 579 same, a loopback IPv4 address is allocated per node. 581 Papadimitriou D. - Internet Draft - Expires May 2002 11 582 For each ring contiguous to a given node, an additional loopback IPv4 583 address is allocated to this node. A ring can be considered as an 584 abstract single node for its neighboring OXC. Consequently, this IP 585 address identifies the abstract node constituted by a ring with 586 respect to the rings connected to this node. 588 From the neighboring rings point-of-view, this loopback IPv4 address 589 enables to reach a given node at any time independently of the status 590 of its incoming links. 592 The loopback IPv4 address is exchanged with the ring contiguous to 593 the node owner of this address but also between nodes belonging to 594 the same ring. These loopback IPv4 addresses are exchanged between 595 neighboring nodes in order to avoid the use of interface address for 596 intra-ring communication and duplicated loopback IPv4 address that 597 are subsequently distributed to neighboring rings. 599 Example: 601 From a nodal point of view, the neighbor relationship is determined 602 by local loopback IPv4 address to each of the neighboring ring from a 603 given node: 605 - Node B (belonging to ring 1 and ring 2) has 2 neighboring rings: 606 - Ring 1 identified by Loopback IP address B01 607 - Ring 2 identified by Loopback IP address B02 609 - Node 1 connected has 1 neighboring ring: 610 - Ring 1 identified by Loopback IP address A1 612 - Node 3 connected has 2 neighboring rings: 613 - Ring 1 identified by Loopback IP address D1 614 - Ring 2 identified by Loopback IP address D2 616 From a ring point of view, the neighbor relationship is determined by 617 the local loopback IPv4 address: 619 - Ring 1 has 3 neighboring rings: 620 - Ring 2 identified by Loopback IP address B21 and E21 621 - Ring 3 identified by Loopback IP address E31 622 - Ring 4 identified by Loopback IP address D41 and E41 624 Consequently, a boundary node belonging to two rings owns two virtual 625 IP addresses. In order to pass from one to ring to the other, the 626 boundary node performs a shortcut. Imagine that Node 1 connected to 627 Ring 1 (through Node A) communicates with the Node 2 connected to 628 Ring 3 (through Node I). Then, the explicit route computed and 629 selected by Node 1 can be [A1 - E3 - Node 2]. However, the actual 630 route followed by the signalling message is [Node 1 - A1 (tunnel1) E3 631 (tunnel2) I3 - Node 2] where tunnel1 could. 633 Papadimitriou D. - Internet Draft - Expires May 2002 12 634 Node 1 ------ A ------ B ------ C 635 | | | 636 | Ring 1 | Ring 2 | 637 | | | 638 Node 3 ------ D ------ E ------ F 639 | | | 640 | Ring 4 | Ring 3 | 641 | | | 642 G ------ H ------ I ------ Node 2 644 3.2.4 Optical Ring Protection Type 646 The Optical Ring Protection Type defines the protection technology 647 supported by nodes belonging to the same ring. 649 The Optical Ring Protection Type (which can be encoded as an 8-bit 650 field) is defined as the combination of the following parameters: 651 - Ring technology: Optical (= 0) or OTH-based (= 1) 652 - Ring protection type: Dedicated (= 0) or Shared (= 1) 653 - Ring protection level: Link-level (= 0) or Path-level (= 1) 654 - Ring protection fibers: 2-fiber (= 0) or 4-fiber (= 1) 655 - Ring switching: ring-switch (= 0) or span-switch (= 1) 656 - Other values (3 bits) are reserved for future use 658 So for a instance, an OCh-DPRing is defined by a 0xA0 protection type 659 and an 4-fiber shared path-level optical ring is defined by a 0x70 660 protection type. Since span-switch is only supported with 4-fiber 661 rings, one must avoid the 2-fiber and span-switch combination. 663 Note the ring technology could also be defined as Transparent (= 0) 664 and All-Optical (= 1) when the optical network topology includes only 665 OXC or PXC respectively. 667 3.2.5 Ring Link Diversity - SRLG 669 The shared link risk groups (SRLGs) are exchanged between nodes 670 belonging to the same ring. This in order to potentially avoid the 671 use of a shared resource that can affect all links belonging to this 672 group in case of failure of this shared resource. For instance, as 673 described in [IPO-SRLG], two LSPs flowing through the same fiber link 674 in the same fiber trunk. 676 [IPO-BUNDLE] extends the SRLGs concept by demonstrating that a given 677 link could belong to more than one SRLG, and two links belonging to a 678 given SRLG may individually belong to two other SRLGs. 680 3.2.6 Ring Metric 682 The ring metric is used to bootstrap the initial ring resource 683 allocation during the ring configuration process. This metric is 684 exchanged during the initial ring configuration and only considered 686 Papadimitriou D. - Internet Draft - Expires May 2002 13 687 by a node if its ring ID corresponds to the one advertised with the 688 ring metric. 690 The ring metric is a composed metric including the following 691 components: the ring absolute weight, the ring capacity and the ring 692 maximum restoration time. 694 1. Ring absolute weight 696 The ring absolute weight translates the number of nodes that belongs 697 to the ring. This value is used during the initial configuration 698 process to determine the number of non-adjacent nodes belonging to 699 the same ring. 701 For instance, it the ring absolute weight metric of given ring is N 702 then by receiving this value (or simply by consulting this value), a 703 node belonging to a given ring knows that the number of non-adjacent 704 nodes belonging to the same ring equals N-3. 706 2. Ring Capacity 708 During the initial configuration process, the ring capacity defines 709 the number of incoming, outgoing and dropped channels (or 710 wavelengths) provisioned at a given node for a given ring ID. These 711 values are defined for the working as well as the protection 712 capacity. The number of potentially available but unused wavelengths 713 by this ring is also announced during the initial configuration 714 phase. These wavelengths are consequently left free for other rings 715 that can be defined using the same node. 717 The ring capacity (per node) is exchanged between adjacent nodes 718 until each node belonging to the same ring has received (N-1) copy of 719 the ring capacity. 721 The knowledge of these values will enable to determine the initial 722 working ring load, protection ring load and spare capacity (also 723 defined as non-allocated ring load) for the newly configured ring. 724 This in turn provides the required information for each node to 725 compute the number of potential LSPs that can pass through (i.e. bar- 726 state) or be dropped (i.e. cross-state). 728 3. Maximum Restoration Time 730 Typically, this static value defines the maximum restoration time 731 (MRT) for a given ring type at the initial configuration time. The 732 MRT values are distributed between nodes in order to know the 733 performance of the other nodes belonging to the same ring. 735 With the current state of the usage of all-optical (for instance, 736 MEMS) technology in OXC enabling less than 10 ms switching time, 737 typical MRT values range between 10 to 50 ms for bi-directional 739 Papadimitriou D. - Internet Draft - Expires May 2002 14 740 rings. For unidirectional rings using optical splitters (as described 741 in [IPO-MULT], typical MRT values are within 1 ms. 743 Note that these values are statically configured and only during the 744 initial ring configuration period. So, they are not considered during 745 the working period of the ring. 747 3.2.6 Ring Protection Policy 749 Ring protection policy refers to the different strategies applicable 750 to optical rings. The ring protection policy includes mainly the ring 751 protection strategy, the ring protection scheme and ring protection 752 priority. 754 1. Strategy 756 The ring protection strategy could be revertive (default for 757 dedicated 1:1 ring protection or shared protection 1:N and M:N ring 758 protection) or non-revertive (default for 1+1 rings). 760 Depending on the ring protection type, the ring protection strategy 761 is determined by the under-laying hardware (or low-layer) opto(- 762 electro-)-mechanical technology providing the automatic protection 763 switching function. However, these considerations are outside of the 764 scope of this document. 766 2. Scheme 768 The ring policy scheme can be configured as provisioned or non- 769 provisioned. The non-provisioned scheme refers to restoration (or re- 770 routing) so that this scheme is not generally used when considering 771 ring protection in optical networks. 773 The provisioned scheme is one used when the protection path or lines 774 are left unused and fully dedicated to protection purposes; switching 775 to these paths will only occur if a working path or line failure need 776 to be recovered. 778 3. Priority/Preemption 780 The prioritization capability refers to the support of initial setup 781 and recovery priority associated with the subsequent link working and 782 protection allocated to the LSP established on top of the emulated 783 ring. Note that the priority support extends to the signalling 784 support of prioritized working and protection LSPs created on a given 785 ring. 787 The preemption capability refers to the support of link working and 788 protection resources pre-emptability in case of link or node failure 789 within a given ring. 791 3.2.7 Summary 793 Papadimitriou D. - Internet Draft - Expires May 2002 15 794 Consequently, the exchange of information between nodes belonging to 795 the same ring enables the common knowledge of the identification and 796 properties that uniquely define a given optical ring. 797 - Ring Identifier 798 - Ring Virtual IP Address 799 - Ring Protection Type 800 - Ring SRLG per link 801 - Ring Metric including the absolute ring weight, the ring capacity 802 and the ring MRT 803 - Ring Policy including ring protection strategy, the ring protection 804 scheme, and the priority/preemption support 806 4. Dynamic Ring Resource Allocation 808 The dynamic ring resource allocation process is closely related to 809 intra-ring traffic engineering (intra-ring TE). The ring resource 810 allocation process is required to dynamically setup Lambda-switched 811 LSP segments on top of emulated rings. 813 4.1 Link TE Resource 815 Link TE resources are dynamically exchanged between nodes belonging 816 to the same ring to provide the necessary information for intra-ring 817 TE. Dynamic Ring Resource Allocation is based on the knowledge of the 818 following link TE resource-related information: 819 - Link identification (or link bundle identification) 820 - Maximum available bandwidth per link 821 - Minimum and maximum reservable bandwidth per link 822 - Link protection type including unprotected 0:1, dedicated 1:1, 823 shared M:N and dedicated 1+1 protection 824 - Link priority associated to the minimum/maximum reservable 825 bandwidth per link 826 - Link priority associated with the link protection type 827 - List of SRLGs per link (in order to compute disjoint working and 828 protection LSP, for instance) 829 - Resource Class/Color defined per link 831 The dynamic exchange of this information (IGP link-state 832 advertisements) during the working period of the ring enables the 833 real-time computation of the value(s) (i.e. the component values) 834 defined for the ring TE metric. 836 4.2 Ring TE Metric 838 The ring traffic engineering metric (ring TE metric) can be 839 considered as a dynamic ring metric whose component value(s) are 840 periodically re-evaluated during the working period of the emulated 841 ring. This ring metric is a composed TE metric including the 842 following components: 843 - a ring weight 844 - a ring load 846 Papadimitriou D. - Internet Draft - Expires May 2002 16 847 - a ring maximum restoration time 849 1. Ring weight 851 In the previous example, the Node A does not know the number of nodes 852 the (i.e. hop count) within a given neighboring ring. To make the 853 distinction between rings, we introduce the concept of ring weight. 854 Ring weight is inversely proportional to number of nodes belonging to 855 a ring multiply by 100. The ring weight is defined as: 857 Working ring weight = (1/[Number of nodes] x 100) x r1 859 where r1 is a weighted integer factor 860 r1 is a user customizable integer whose default value equal 1 862 For instance, in the above example each ring have a weight of 25 863 since 1/[Number of nodes = 4] x 100. 865 However, this definition does not allow discriminating between 866 working and protection path. So we define a working ring weight and a 867 protection ring weight (this applies only to bi-directional rings). 869 For bi-directional rings, the ring weight is defined in two flavors: 870 - Working ring weight = (1/[Number of nodes] x 100) x r1 871 - Protection ring weight = (100 - [Working ring weight]) x r2 873 where r1 and r2 are weighted integer factors defined by default as r1 874 = 1 and r2 = 1. 876 2. Ring Load 878 The ring load is only defined for bi-directional rings. The working 879 ring load quantity defines, for each direction of propagation, the 880 largest number of working LSPs (in any fiber link) flowing in 881 opposite direction of the protection LSPs. The working ring load is 882 defined at each time interval as: 884 Working ring load = [Number of working LSP] 886 However, this definition does not give the relative working load of 887 the ring compared to its total capacity. So, to normalize the working 888 ring load, this value is divided by the total ring capacity (in terms 889 of total number of LSPs). 891 Working ring load = [Number of working LSP]/[Total number of LSPs] 893 Correspondingly, the protection ring load will be defined as the 894 number of protection LSPs divided by the total ring capacity (in 895 terms of total number of LSPs). The protection ring load is defined 896 at each time interval as: 898 Papadimitriou D. - Internet Draft - Expires May 2002 17 899 Protection ring load = [Number of protection LSP]/[Total number of 900 LSPs] 902 Consequently, the working ring load, the protection ring load and the 903 non-allocated ring load are defined by the following formulas: 905 Working Ring Load = ([Number of working LSP]/[Ring capacity] x 100) x 906 r3 908 Protection Ring Load = ([Number of protection LSP]/[Ring capacity] x 909 100) x r4 911 Unallocated Ring Load = ((1 - ([Working Ring Load] + [Protection Ring 912 Load])/[Ring Capacity]) x 100) x Mean(r3,r4) 914 Where the r3 and r4 parameters are weighted integer factors, defined 915 by default as r3 = 1 = r4. 917 3. Maximum Restoration Time 919 Typically, this value defines the maximum restoration time (MRT) for 920 a given ring type. Typical values are: 921 - Bi-directional rings (shared protection): 10 to 50 ms 922 - Unidirectional rings (dedicated protection): 1 ms 924 So, we define the associated metric value as: 926 MRT = (MRT[N+1] x 100) x r5 928 In this definition, the r5 parameter is a weighted integer factor 929 defined by default as equal to 1. Comparing to the MRT defined in the 930 ring metric, the values considered here are dynamic. The maximum 931 restoration time computation per ring depends on the failure history 932 of that ring. Each time a failure is experienced by a ring the MRT 933 value is adapted through the use of the following computation: 935 If MRT[N+1] > MRT[N] 936 then MaxMRT[N+1] = MRT[N] + (k1 x MRT[N]) 937 and MRT[N+1] = Mean(MaxMRT[N+1]; MRT[N]) 939 If MRT[N+1] < MRT[N] 940 then MinMRT[N] = MRT[N] - (k2 x MRT[N]) 941 and MRT[N+1] = Mean(MRT[N]; MinMRT[N+1]) 943 Where MRT[N+1] is defined as the Maximum Restoration Time when a 944 given ring has already experienced N failures (so that N defines the 945 number of ring restoration process occurrence). The k1 and k2 are 946 defined as weighting factors (0 < k1 < 1 and 0 < k2 < 1) whose values 947 are by default k1 = 1 and k2 = 1. 949 Consequently, the Ring TE Metric is defined as: 951 Papadimitriou D. - Internet Draft - Expires May 2002 18 952 Ring TE Metric = (Working Ring Weight x r1 | Protection Weight x r2) 953 + (Working Ring Load x r3 | Protection Load x r4) 954 + (Maximum Restoration Time x r5) 956 The corresponding advertisement will include both the working and the 957 protection part of the metric. 959 5. Ring Protection in Optical Networks 961 Within optical networks, the purpose of the ring protection 962 mechanisms is to incorporate optical layer survivability in network- 963 layered structures. Even if some of the higher layers have their own 964 protection mechanisms, by incorporating survivability mechanisms at 965 multiple layers leads to the following issues: 966 - the protection function allocation to each of the layers 967 - the coordination of the protection functions applied at each layer 968 during failure recovery process 970 Nevertheless, as described in [OPT-MRPS], providing optical layer 971 survivability through ring protection has been strongly suggested by 972 arguing a combination of optical ring protection with optical linear 973 protection as well as additional restoration mechanism provides the 974 best optical network survivability. 976 5.1 Escalation Strategy 978 The escalation strategy is defined by the set of detection functions 979 describing the originating failure, the protection functions applied 980 within recovery process to recover the failure and the interaction 981 between the upper and/or lower layers protection functions applied 982 during the recovery process. The escalation strategies are governed 983 either by arbitrarily setting failure detection and recovery 984 completion time (using hold-off timers) or by explicit message 985 exchange between the layers. 987 Escalation strategies (also referred to as inter-working strategy) 988 have been proposed in [IPO-POES] and summarized here: 989 - Bottom-up strategy starts at closest layer to the failure 990 (generally the bottom layer) and escalates toward the upper layer 991 upon expiration of the recovery timer (hold timer). This timer is 992 defined in such a way that is allocates "enough time" the lower 993 layer(s) to detect the failure, execute the recovery process and 994 recovery completion time before triggering recovery process defined 995 at the higher layer(s). 996 - Top-down strategy starts at the upper(most) layer and escalates 997 downward to the lower layer(s); depending on the working level, the 998 top-down strategy is suitable when each of the layers define Class- 999 of-Services (CoS) so that the escalation strategy might take this 1000 CoS into account when executing the recovery process. 1002 5.2 Bottom-Up Strategy 1004 Papadimitriou D. - Internet Draft - Expires May 2002 19 1005 We assume here a classical Bottom-up strategy since it has the 1006 shortest recovery time (with respect to the Top-down escalation 1007 strategy), and define the threshold at which the upper-layer 1008 protection needs to be "executed". 1010 In optical rings, the following escalation strategy can be defined 1011 (here we do not assume FSC capable OXC interfaces, so that GMPLS 1012 signalling is not considered at the lowest layer) 1014 Packet Layer <==> PSC interface <==> GMPLS Signalling 1015 ^ ^ 1016 | | 1017 | | 1018 | | 1019 Lambda Layer <==> LSC interface <==> GMPLS Signalling 1020 ^ ^ 1021 | | 1022 | | 1023 | | 1024 Fiber Layer <==> FSC Interface <==> Layer-1 Mechanism 1026 Compared to TDM SDH/Sonet Rings control through GMPLS signalling 1027 [GMPLS-SIG] or Optical Transport Networks as defined in [ITUT-G872] 1028 and [ITUT-G709]): 1030 Packet Layer <==> PSC interface <==> GMPLS Signalling 1031 ^ ^ 1032 | | 1033 | | 1034 | | 1035 Path (OCh) Layer <==> OCh (G.709) interface <==> GMPLS Signalling 1036 ^ ^ 1037 | | 1038 | | 1039 | | 1040 MS (OMS) Layer <==> Physical interface <==> Layer-1 Mechanism 1041 ^ ^ 1042 | | 1043 | | 1044 | | 1045 RS (OTS) Layer <==> Physical interface <==> Layer-1 Mechanism 1047 Note: Layer-1 mechanism can be used in conjunction with [LMP] and 1048 [LMP-WDM]. 1050 Or eventually when considering the G.709 ODUk Switching Layer (also 1051 referred to as Digital Path Layer): 1053 Papadimitriou D. - Internet Draft - Expires May 2002 20 1054 Packet Layer <==> PSC interface <==> GMPLS Signalling 1055 ^ ^ 1056 | | 1057 | | 1058 | | 1059 Packet Layer <==> TDM (G.709) interface <==> GMPLS Signalling 1060 ^ ^ 1061 | | 1062 | | 1063 | | 1064 Path (OCh) Layer <==> OCh (G.709) interface <==> GMPLS Signalling 1065 ^ ^ 1066 | | 1067 | | 1068 | | 1069 MS/RS (OMS/OTS) <==> Physical interface <==> Layer-1 Mechanism 1071 This approach is based on the common coordination achieved by 1072 resorting escalation strategies. At each level, the resiliency scheme 1073 is activated sequentially starting from the lower to the upper layer. 1074 This implies that at each level the detection of a failure condition 1075 (and restoration time) triggers either a protection/restoration 1076 mechanism and if the protection/restoration completion time is 1077 reached then triggers an upper-layer protection/restoration 1078 mechanism. 1080 5.3 Ring Protection Mechanisms 1082 In this section the two generic ring protection mechanisms are 1083 discussed. The main difference between these mechanisms is that the 1084 dedicated protection performs a physical-layer level protection 1085 switching while the shared protection needs a dedicated O-APS 1086 signalling protocol to synchronize the execution of the protection 1087 switching mechanism. 1089 5.3.1 Dedicated Protection 1091 Dedicated LSP protection can be easily achieved by splitting the 1092 incoming optical signal and send the one copy of the output signal 1093 into working wavelength (or fiber) and the other copy into the 1094 protection wavelength (or fiber). 1096 This results in two copies of the signal propagating the ring in 1097 opposite directions. The far-end (or receive-end) switches to the 1098 protection wavelength (or fiber) if a degradation or failure occurs. 1099 The proposed mechanism can restore a single link failure or a single 1100 node failure. 1101 Moreover, since the far-end (receiving end) needs to notify the near- 1102 end (transmitting end) of the failure, an O-APS signalling mechanism 1103 is not required. However, when a link failure is detected on the 1104 working ring, the far-end switch to the protection ring (in the 1106 Papadimitriou D. - Internet Draft - Expires May 2002 21 1107 opposite direction) but for any wavelength flowing through this link, 1108 so that only a bulk LSP protection switching is achieved by using 1109 this technique. 1111 By using the optical signal splitting technique (as described in 1112 [IPO-MULT]), fast protection is provided for 1+1 LSP protection. 1113 However, this technique applies only for unidirectional LSP 1114 protection rings. With this type of rings the optical signal is split 1115 on both wavelengths (fibers) at the transmission end. 1117 5.3.2 Shared Protection 1119 Shared protection is mainly based on the use of an O-APS signalling 1120 protocol (using the signalling IP-based control-plane). The 1121 requirements as well as the specifications for the specification of 1122 such an IP-based protocol need to be seriously determined in order to 1123 achieve a fast protection switching mechanism. The specifications of 1124 the O-APS protocol are extensively detailed in [IPO-OAPS]. 1126 6. Routing in Optical Rings and Hybrid Mesh-Ring Networks 1128 In optical networks, the following hierarchical routing model can be 1129 considered: 1130 - the intra-domain interfaces are included in an IGP (more precisely 1131 link-state routing protocols) routing protocol instance included 1132 within the same autonomous-system (AS) 1133 - the inter-domain interfaces are defined between autonomous-systems 1134 running over eBGP routing protocol. 1136 The eBGP protocol is running between border LSRs (which from the 1137 OSPF point-of-view are considered as an Autonomous System Boundary 1138 Router - ASBR). The hierarchical optical network model provides the 1139 capacity to connect several autonomous systems (i.e. optical domains) 1140 together through eBGP protocol. 1142 6.1 Intra-Domain Routing 1144 The optical network architecture considered here is build such as the 1145 corresponding control plane defines an hierarchical optical topology 1146 as described in [IPO-FRAME]. Consequently, intra-domain routing can 1147 be considered when the IP-based control plane defines an OSPF 1148 Autonomous System (AS) on top of an hierarchical optical domain 1149 (which defines the transport plane). The same considerations can be 1150 applied when using IS-IS IGP protocol in hierarchical optical 1151 networks. 1153 With the intra-domain architecture, transparent optical network 1154 devices (i.e. OXC including O/E/O conversion) are located at the 1155 border of the corresponding areas. Consequently, OXC might be 1156 considered as internal LSR as well as border LSR. All-optical network 1157 devices (i.e. PXC without O/E/O conversion) are predominantly 1159 Papadimitriou D. - Internet Draft - Expires May 2002 22 1160 configured as internal LSR but might in particular cases be 1161 configured as border LSR. 1163 ++++++++++++++ ++++++++++++++ 1164 + A ------ B + + H ------ I + 1165 + | | + + | | + 1166 + | Area10 | + + | Area20 | + 1167 + | | XXXXXXXXXX | | + 1168 + D ------ C ---------- E ------ J + 1169 +++++++++X | | X+++++++++ 1170 X | | X 1171 X | Area 0 | X 1172 X | | X 1173 +++++++++X | | X+++++++++ 1174 + K ------ G ---------- F ------ N + 1175 + | | XXXXXXXXXX | | + 1176 + | Area30 | + + | Area40 | + 1177 + | | + + | | + 1178 + M ------ L + + P ------ O + 1179 ++++++++++++++ ++++++++++++++ 1181 Taking into account this optical network topology: 1182 - Ring CEFG defines backbone area 0 1183 - Ring ABCD, HIJE, KGLM and FNOP define non-backbone area 1185 In this hierarchical network topology, each of these nodes can be 1186 considered as an abstract node so that each of them can also be 1187 considered as defining an optical ring. Moreover, each of these areas 1188 can include internal all-optical rings. However, in that case, the 1189 only restriction is related to the Area Border Routers (ABR i.e. 1190 border LSR) that can not be all-optical PXC. In order to avoid 1191 optical signal regeneration related problems, one can consider here 1192 that border LSRs are O/E/O transparent devices like OXCs. 1194 6.2 Inter-domain Routing 1196 Inter-domain Optical Routing is considered when defining inter- 1197 optical domain routing between several carriers. In the most basic 1198 network topology, optical domains (i.e. BGP AS) are inter-connected 1199 through direct links (or redundant links) combined with linear 1200 protection mechanisms as represented in the following figure: 1202 ++++++++++++++ ++++++++++++++ 1203 + A ------ B + + H ------ I + 1204 + | | + + | | + 1205 + | AS 10 | + + | AS 20 | + 1206 + | | + + | | + 1207 + D ------ C ========= E ------ J + 1208 +++++++++++|++ ++|+++++++++++ 1209 | | 1211 Papadimitriou D. - Internet Draft - Expires May 2002 23 1212 direct --> | | 1213 | | 1214 +++++++++++|++ ++|+++++++++++ 1215 + K ------ G ========= F ------ N + 1216 + | | + + | | + 1217 + | AS 30 | + + | AS 40 | + 1218 + | | + + | | + 1219 + M ------ L + + P ------ O + 1220 ++++++++++++++ ++++++++++++++ 1222 In this topology, the Nodes CEFG can define an inter-domain ring. 1223 This enhancement provides higher resiliency to the classical inter- 1224 domain connections since in that case ring protection mechanism can 1225 be used. However, the most reliable topology will be achieved when 1226 the optical domains are inter-connected through a BGP Transit AS. 1227 When considering a Transit AS, the Client AS can be inter-connected 1228 by using optical rings or direct links to the Transit AS. 1230 As mentioned above the use of a meshed inter-connectivity between 1231 nodes does not preclude the use linear protection (and restoration) 1232 mechanisms such as dedicated 1+1 or shared (1:1, 1:N, M:N) LSP 1233 protection. 1235 The following figure compares optical ring from direct link inter- 1236 connection approach: 1238 + + + + 1239 �|�+��������+�|� | + + | 1240 ---�C-+--------+-E�--- ---C-+--------+-E--- 1241 +++�+++ +++�+++ +++++++ +++++++ 1242 �| |� | | 1243 +�++++++++++++++�+ ++++++++++++++++++ 1244 +�Q------------R�+ + Q------------R + 1245 +�|������������|�+ + | | + 1246 + | Transit AS | + + | Transit AS | + 1247 +�|������������|�+ + | | + 1248 +�T------------S�+ + T------------S + 1249 +�++++++++++++++�+ ++++++++++++++++++ 1250 �| |� | | 1251 +++�+++ +++�+++ +++++++ +++++++ 1252 ---�G-+--------+-F�--- ---G-+--------+-F--- 1253 �|�+��������+�|� | + + | 1254 + + + + 1256 Optical Rings Direct Links 1258 As mentioned before, a trade-off between link (or wavelength) 1259 redundancy and lost capacity need to be defined. However, these 1260 considerations are out of the scope of this document. 1262 6.3 Inter-Ring Traffic-Engineering 1264 Papadimitriou D. - Internet Draft - Expires May 2002 24 1265 As described in the previous section, the network hierarchical model 1266 considered is divided into Autonomous Systems (ASs), where each AS is 1267 divided into IGP areas to allow the hiding, aggregation and 1268 summarization of routing information. The hierarchical routing model 1269 currently can be extended for traffic engineering as it hides the 1270 route taken by a LSP to the destinations in the other routing areas. 1271 Hence, from the TE perspective, requirements such as path selection 1272 and crank-back mechanism need different architectural additions to 1273 the existing link-state routing and signaling protocols for inter- 1274 area LSP setup. The protection requirements as well as crank-back 1275 mechanisms can be implemented by using the optical ring techniques 1276 described in this document. 1278 Note that in a fully distributed approach, since LSRs in different 1279 AS's have different views of the network at any given time, re- 1280 routing and crank-back mechanisms are needed. This approach requires 1281 also to clearly defining when the steady state of the optical network 1282 is reached in order to execute the protection/restoration mechanisms 1283 specified in the escalation strategy to apply when failure(s) occurs. 1284 The problems related to LSP protection/restoration are also described 1285 in [IPO-REST]. 1287 Traffic engineering (TE) practice currently involves the setup and 1288 use of Label Switched Paths (LSPs) as dedicated bandwidth pipes 1289 between two end points (i.e. between an ingress and an egress LSR). 1290 LSPs can be setup across several LSRs through the use of dynamically 1291 computed path. Since this memo focuses on fully distributed CSPF path 1292 computation, we consider here that the routes can be computed 1293 dynamically through the use of online constraint-based routing 1294 algorithms such as incremental Linear or Heap Dijkstra Algorithm (or 1295 Dijkstra-like algorithms for non-additive metrics) as described for 1296 instance in [SPT-DYN]). 1298 The online constraint-based routing model requires: 1299 (1) a set of flooding mechanism to maintain the state of TE-related 1300 information within the optical network topology 1301 (2) a constraint-based routing process implemented on certain LSRs 1302 that serve as ingress LSRs for the LSPs, 1303 (3) a topology change(s) within the optical domain does not result in 1304 a complete re-computation of the routes 1306 Most of the traffic engineering extensions for intra-area TE routing 1307 are described in [OSPF-TE] and [GMPLS-OSPF] the latter in particular 1308 when considering intra-area GMPLS TE routing. Note that new traffic 1309 engineering attributes can be defined in future versions of this 1310 document. We describe here the TE extensions for inter-ring TE 1311 routing in optical ring topologies when considering summarization of 1312 the TE values at boundaries (see also [OSPF-IRTE] concerning 1313 summarization of TE attributes). 1315 Papadimitriou D. - Internet Draft - Expires May 2002 25 1316 As described in [OSPF-IRTE], traffic engineering (TE) summary LSA can 1317 be originated at Area Border Router (ABR) into an area. This TE 1318 summary LSA is a type-10 opaque LSA flooded within the area. The 1319 functionality of the TE summary LSA is similar to the one of summary 1320 LSA of standard OSPF [RFC2328], but in addition it carries the 1321 traffic engineering metrics to the remote destination (IP network or 1322 ASBR). The inter-ring TE summary LSA described here has exactly the 1323 same functionality except that the corresponding LSA is generated at 1324 ring boundary nodes. 1326 6.3.1 Ring Count 1328 The ring count is the cost in rings to reach the destination network 1329 (or the destination ring) from the source node (or the source ring). 1330 This parameter is equivalent to the hop count defined in [OSPF-IRTE] 1331 since a ring appears as an abstract node for the neighboring rings or 1332 OXCs (not belonging to the same ring). The ring count (as the hop 1333 count) is an additive metric. Note that the ring count can be 1334 generalized to an additive weighted metric. 1336 6.3.2 Maximum Reservable Bandwidth 1338 The maximum reservable bandwidth is defined as the smallest maximum 1339 reservable bandwidth among all the rings included into the path from 1340 the source to the destination. 1342 Note the maximum reservable bandwidth should be the same for the 1343 working and the protected path. 1345 6.3.3 Minimum Reservable Bandwidth 1347 The minimum reservable bandwidth is defined as the largest minimum 1348 reservable bandwidth among all the rings included into the path from 1349 the source to the destination. 1351 Note the minimum reservable bandwidth should be the same for the 1352 working and the protected path. 1354 6.3.4 Delay 1356 The delay attribute is defined as the delay cost to reach the 1357 destination ring in microseconds. The delay is defined an average 1358 delay taking into account the delay introduced by the worst case 1359 protection path and best case working path since this value can not 1360 up to now be updated dynamically. The delay is an additive metric 1361 that could be generalized to an additive weighted metric. 1363 Note that the delay of the working path could be different from the 1364 delay of the protected path. 1366 6.3.5 Resource Class/Coloring 1368 Papadimitriou D. - Internet Draft - Expires May 2002 26 1369 The resource class or color of the destination network is a 1370 combination of the colors for the various ringed paths to the 1371 destination network. Path coloring technique can be found in [IPO- 1372 PATH]. 1374 Path coloring can be used to prune resources as a first step of the 1375 LSP route computation and as a tie when two distinct routes having 1376 the same Inter-Ring TE Metric (see section 6.3.6) to the same 1377 destination network may be used but only differ from their color. In 1378 that case, the choice of one route or another is a local policy 1379 matter. 1381 6.3.6 Inter-ring TE Metric 1383 The inter-ring TE metric is defined as the TE metric representing the 1384 TE cost of reaching the destination network (or the destination ring) 1385 from the advertising ring. 1387 This metric is composition of ring TE metrics (described in section 1388 4.2) defined by the following formula: 1390 Inter-Ring TE Metric = 1391 (Working Ring Weight x r1 | Protected Weight x r2) 1392 + (Working Ring Load x r3 | Protected Load x r4) 1393 + (Maximum Restoration Time x r5) 1395 So that the inter-ring TE metric is defined as the weighted sum of 1396 the ring metrics and representing the traffic-engineering cost of 1397 reaching the destination ring (i.e. Ring N) from the advertising ring 1398 (i.e. Ring 1). 1400 Ring TE Metric = k[1] x Ring Metric 1 + k[2] x Ring Metric 2 1401 k[n-1] Ring Metric N-1 ... k[n] x Ring Metric N 1403 6.4 Routing Protocol Extensions for Dynamic Ring Configuration 1405 We describe here the IGP routing protocol extensions needed in order 1406 to enable dynamic ring configuration within an area (intra-area 1407 routing) between areas (inter-area routing). 1409 6.4.1 Opaque LSA 1411 Opaque LSA are application specific link-state advertisements defined 1412 in [OSPF-OPA] used mainly for IGP traffic engineering (TE) extension 1413 purposes, see for instance [OSPF-TE] concerning intra-area TE routing 1414 and [OSPF-IRTE] concerning inter-area TE routing. 1416 The [RFC2370] describing the Opaque LSAs concepts for application 1417 specific information distributed additionally to the IGP routing 1418 information. In [OSPF-OPA], three types of Opaque LSA were defined: 1419 - Type-9 Opaque LSA: link-local scope 1420 - Type-10 Opaque LSA: area-local scope (or intra-area scope) 1422 Papadimitriou D. - Internet Draft - Expires May 2002 27 1423 - Type-11 Opaque LSA: Autonomous System (AS) scope (or inter-area 1424 scope) 1426 The flooding scope associated with each Opaque link-state type is 1427 defined as follows. 1428 - Type-9 Opaque LSAs are not flooded beyond the local sub-network. 1429 - Type-10 Opaque LSAs are not flooded beyond the borders of their 1430 associated area. 1431 - Type-11 Opaque LSAs are flooded throughout the Autonomous System 1432 (AS) and is equivalent to the flooding scope of AS-external (type- 1433 5) LSAs. 1435 As a generic rule, see [RFC2370], when flooding Opaque-LSAs to 1436 adjacent neighbors, an opaque-capable router looks at the neighbor's 1437 opaque capability. Opaque LSAs are only flooded to opaque-capable 1438 neighbors. When a non-opaque-capable router inadvertently receive 1439 Opaque LSAs, it simply discard the Opaque LSA. 1441 Consequently, to achieve intra-area dynamic ring configuration we use 1442 Opaque LSAs of Type 10 area-local flooding scope. 1444 6.4.2 Opaque LSA Header 1446 Opaque LSAs are types 9, 10 and 11 link-state advertisements. The 1447 Link-State ID [RFC2328] of the Opaque LSA is divided into an Opaque 1448 Type field (8-bit sub-field) and a Opaque Type-specific ID (24-bit 1449 sub-field). The range of topological distribution (i.e., the flooding 1450 scope) of an Opaque LSA is identified by its link-state type. 1452 In Opaque LSAs are application specific LSAs meaning that their 1453 payload has meaning only within a certain application; otherwise, 1454 they will be ignored. The Opaque Type that is contained in the Opaque 1455 Type field identifies the type of the application. 1457 The Opaque Type-specific ID (i.e. Opaque ID) is a 24-bit sub-field 1458 sub-divided in a reserved sub-field (8 MSB) and a Source specific 1459 sub-field (16 LSB). 1461 0 1 2 3 1462 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 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | LS age | Options | LS Type | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 | Opaque Type | Opaque ID | 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | Advertising Node ID | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | LS sequence number | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | LS checksum | Length | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 Papadimitriou D. - Internet Draft - Expires May 2002 28 1476 where LS Type value = 9, 10 or 11 1478 For the purpose of dynamic ring configuration, only Opaque LSA Type- 1479 10 will be considered. Moreover the dynamic ring configuration Opaque 1480 Type still remains to be determined. 1482 6.4.3 Opaque LSA Payload 1484 As described in [OSPF-OPA], the Opaque LSA payload consists of one or 1485 more nested Type/Length/Value (TLV) structures. The format of the 1486 Opaque LSA TLV structure is defined as: 1488 0 1 2 3 1489 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 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | Type | Length (in bytes) | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | Value | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 The following additional TLV need to be defined in order to enable 1497 dynamic ring configuration through the use of application-specific 1498 Opaque LSAs. 1500 1. Ring ID TLV 1502 The Ring ID is defined as a 32-bit integer field that uniquely 1503 identifies a given ring within a given optical domain (i.e. 1504 administrative authority). 1506 0 1 2 3 1507 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 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 | Type (TBD) | 4 | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | Ring ID | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 A additional field might be defined in the future to identify the 1515 Autonomous System number (16-bit) into which the ring is included. 1517 2. Ring Virtual Address TLV 1519 Each node included within a given ring shares a unique virtual IPv4 1520 Address with other nodes belonging to the same ring. The IPv4 address 1521 is uniquely defined per administrative authority. This information is 1522 exchanged between nodes by using the following TLV: 1524 0 1 2 3 1525 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 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | Type (TBD) | 4 | 1529 Papadimitriou D. - Internet Draft - Expires May 2002 29 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | Virtual IPv4 Ring Address | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 3. Loopback IP Address TLV 1536 One loopback IPv4 address is allocated per node in order to avoid 1537 communication disruption between nodes belonging to the same ring 1538 when a given node interface becomes unreachable. The local loopback 1539 IPv4 address must be the first one included in the loopback IPv4 1540 address list. 1542 For each ring contiguous to a given node, an additional loopback IPv4 1543 address is allocated. Since a ring is viewed as an abstract single 1544 node for its neighboring OXC, these loopback IP addresses identify 1545 the abstract node constituted by a ring for the neighboring nodes 1546 (external to this ring) and neighboring rings. 1548 0 1 2 3 1549 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 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 | Type (TBD) | n x 4 | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | Loopback IPv4 Address 1 | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | | 1556 / ... / 1557 | | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | Loopback IPv4 Address n | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 4. Ring Protection Type TLV 1564 The Optical Ring Protection Type (encoded as an 8-bit flagged field) 1565 is defined as: 1566 - Ring technology: Optical (Bit0=0) or OTH-based (Bit0=1) 1567 - Ring Protection: Dedicated (Bit1=0) or Shared (Bit1=1) 1568 - Ring Protection level: Link-level (Bit2=0) or Path-level (Bit2=1) 1569 - Ring Protection fibers: 2-fiber (Bit3=0) or 4-fiber (Bit3=1) 1570 - Ring switching: ring-switch (Bit4=0) or span-switch (Bit4=1) 1571 - Other values (3 bits) are reserved for future use 1573 The corresponding TLV is defined as: 1575 0 1 2 3 1576 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 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | Type (TBD) | 4 | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Protection | Reserved | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 Papadimitriou D. - Internet Draft - Expires May 2002 30 1584 5. Link TLV 1586 To encode the list of SRLG(s) to which a given link belongs, we 1587 propose to use the Link TLV by including the following sub-TLVs: 1588 - Link ID (32-bit) 1589 - Link Local Interface ID (32-bit) 1590 - Link Remote Interface ID (32-bit) 1591 - Link Encoding Type (8-bit) 1592 - Link Protection Type (8-bit) 1593 - List of SRLG(s) (n x 32-bit) 1595 The corresponding TLV are already defined in [GMPLS-OSPF] and [OSPF- 1596 TE]. Note that for optical rings, the relevant Link Protection Type 1597 are dedicated 1+1, dedicated 1:1, shared M:N and unprotected 0:1. 1599 Additional sub-TLVs can also be included within the Link TLV for 1600 intra-ring traffic engineering purposes. So, we can refer to these 1601 sub-TLVs as Link TE sub-TLVs: 1602 - Maximum Available Bandwidth per link 1603 - Minimum and Maximum Reservable Bandwidth per link 1604 - Link Priority associated to Minimum/Maximum Reservable Bandwidth 1605 - Link Priority associated with the Link Protection Type 1606 - Resource Class/Color defined per link 1608 The link resource allocation is performed dynamically here; 1609 consequently the Link TLV does not need to include the Ring ID to 1610 which this link might be allocated (or de-allocated) during the 1611 working period of the ring. A given link can include several 1612 wavelengths belonging to more than one ring if this is a shared link. 1613 This means that the per-ring resource allocation 1615 Note also that even if a fiber link can belong to more than one ring 1616 (if the link is defined as a boundary link) the wavelengths available 1617 on that link when allocated to one ring, they can not be shared by 1618 the other ring. 1620 6. Ring Metric TLV 1622 As described in section 3.6, the ring metric is a component metric 1623 including the ring absolute weight, the ring initial MRT and the ring 1624 capacity. 1626 The corresponding TLV is defined as follows: 1628 0 1 2 3 1629 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 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | Type (TBD) | 20 | 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | Weight | Initial MRT | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 Papadimitriou D. - Internet Draft - Expires May 2002 31 1637 | R | Incoming | Outgoing | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | R | Dropped | Reserved | 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 | R | Incoming | Outgoing | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | R | Unused | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 The Ring Metric TLV includes: 1647 - Ring absolute weight (8-bit): number of nodes belonging to the same 1648 ring ID 1649 - Ring initial MRT (24-bit): in microsecond units 1650 - Ring capacity: 1651 . number of working wavelengths: incoming (15-bit), outgoing 1652 (15-bit) and dropped (15-bit) 1653 . number of protection wavelengths: incoming (15-bit) and 1654 outgoing (15-bit) 1655 . number of unused wavelengths (30-bit) for this ring 1657 7. Ring Protection Policy TLV 1659 Ring protection policy refers to the different strategies applicable 1660 to optical rings. The ring protection policy includes mainly the ring 1661 protection strategy, the ring protection scheme and ring resource 1662 priority and preemptability support. The Ring Protection Policy TLV 1663 format is defined as: 1665 0 1 2 3 1666 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 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 | Type (TBD) | 4 | 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 |0|1|2|3| Reserved | 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 The values are defined as follows: 1675 The ring protection strategy (bit-0): 1676 - Bit 0 set to 0 defines a non-revertive strategy 1677 - Bit 0 set to 1 defines a revertive strategy 1679 The ring protection scheme (bit-1): 1680 - Bit 1 set to 0 defines a provisioned scheme 1681 - Bit 1 set to 1 defines a non-provisioned scheme 1683 The ring resource Priority-Preemption (bit-2 and bit-3): 1684 - Bit 2 set to 0 enables setup pre-emptability of working and 1685 protection link resources during LSP setup process (meaning 1686 implicit priority support for link resources) 1688 Papadimitriou D. - Internet Draft - Expires May 2002 32 1689 - Bit 2 set to 1 disables setup pre-emptability of working and 1690 protection link resources during LSP setup process 1691 - Bit 3 set to 0 enables recovery pre-emptability of working and 1692 protection link resources during LSP recovery process (meaning 1693 implicit priority support for link resources) 1694 - Bit 3 set to 1 disables recovery pre-emptability of working and 1695 protection link resources during LSP recovery process 1697 Other bits (bit 4 to 31) are reserved for future use. 1699 6.5 Routing Protocol Extensions for Dynamic Ring Resource Allocation 1701 The only additional TLVs to define as additional Opaque LSA payload 1702 is the Ring TE Metric TLV. Other traffic engineering extensions such 1703 as Link TE TLVs have already been defined in [OSPF-TE] and [GMPLS- 1704 OSPF]. 1706 1. Ring TE Metric TLV 1708 The Ring TE Metric is a component metric including the ring weight, 1709 the ring load and the ring MRT. 1711 The Working TE Metric (16-bit) part of the Ring TE Metric includes 1712 the following components 1713 - the working ring weight 1714 - the working ring load 1715 - the computed MRT 1717 The Protection TE Metric (16-bit) part of the Ring TE Metric includes 1718 the following components: 1719 - the protection ring weight 1720 - the protection ring load 1721 - the computed MRT 1723 The Ring TE Metric TLV is encoded as: 1725 0 1 2 3 1726 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 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | Type (TBD) | 4 | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | Working TE Metric | Protection TE Metric | 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1733 7. Signaling Extensions in Ring Protected optical networks 1735 The signaling extensions are related to the following functions: 1736 - signalling of the working and the protected path from source ring 1737 node to the destination ring node 1738 - specific signaling extension in order to support drop-and-continue 1739 functionality; this is equivalent to define signalling extension 1740 for point-to-multipoint LSP 1742 Papadimitriou D. - Internet Draft - Expires May 2002 33 1743 Drop-and-continue function can be required when considering protected 1744 ring interconnection: 1745 - For dedicated-protection ring inter-connection: drop-and-continue 1746 function is used together with path selector function 1747 - For shared-protection ring inter-connection: drop-and-continue 1748 function is used together with service selector function 1749 - For both type of ring are inter-connected: drop-and-continued is 1750 used together with path selector function (dedicated-protection 1751 ring) and service selector function (shared-protection ring) 1753 7.1 Intra-ring signalling extension 1755 When entering the ring, the signaling of the working and the 1756 protected channel need to be executed simultaneously. 1758 The principle defined for this purpose is to 'split' the signaling 1759 message (corresponding to the LSP create message) for the working and 1760 protected path through the corresponding signalling channel. For this 1761 purpose, the same technique as the one defined in [IPO-REST] can be 1762 applied. The proposed mechanism applied to emulated rings provides 1763 the suitable signalling extensions for the creation of backup LSP 1764 segments from the ingress to egress ring node when LSP protection is 1765 required. 1767 [IPO-MULT] proposes a more efficient mechanism to achieve this by 1768 considering the split of the physical optical signal. In that case, 1769 fast protection is provided for the 1+1 protected LSP. However, this 1770 technique applies only for unidirectional LSP protection rings. With 1771 this type of rings the optical signal is split on both wavelengths 1772 (fibers) at the transmission end. This results in two copies of the 1773 signal propagating the ring in opposite directions. The far-end (or 1774 receive-end) switches to the protection wavelength (or fiber) if a 1775 failure occurs. The proposed mechanism can restore a single link 1776 failure or a single node failure. 1778 When using 1+1 LSP protection, since the far-end (receiving end) does 1779 need to notify the near-end (transmitting end) of the failure, an O- 1780 APS signalling mechanism is not required. The decision is made at the 1781 far-end on an LSP-by-LSP basis. 1783 7.2 Inter-ring signalling extension 1785 Inter-ring signalling extensions are considered for drop-and-continue 1786 ring inter-connection. In this case, the signalling message (i.e. the 1787 LSP create message) need to be continued meaning duplicated when 1788 reaching the primary destination node (far end) for that LSP. However 1789 only one LSP must be defined (in particular only one LSP segment 1790 needs to be defined from the ingress to egress ring nodes). Details 1791 concerning inter-ring signalling extensions are left for further 1792 study. 1794 Papadimitriou D. - Internet Draft - Expires May 2002 34 1795 8. Security Considerations 1797 Security considerations are left for further study. 1799 9. References 1801 1. [GMPLS-ARCH] E. Mannie et al., 'Generalized Multi-Protocol Label 1802 Switching (GMPLS) Architecture,' Internet Draft, draft-ietf-ccamp- 1803 gmpls-architecture-00.txt, July 2001. 1805 2. [GMPLS-CRLDP] P. Ashwood-Smith, L. Berger et al., 'Generalized 1806 MPLS Signaling - CR-LDP Extensions,' Internet Draft, draft-ietf- 1807 mpls-generalized-cr-ldp-04.txt, July 2001. 1809 3. [GMPLS-ISIS] K. Kompella et al., 'IS-IS Extensions in Support of 1810 Generalized MPLS,' Internet Draft, draft-kompella-isis-gmpls- 1811 extensions-04.txt, September 2001. 1813 4. [GMPLS-OSPF] K. Kompella et al., 'OSPF Extensions in Support of 1814 Generalized MPLS,' Internet Draft, draft-ietf-ccamp-ospf-gmpls- 1815 extensions-00.txt, September 2001. 1817 5. [GMPLS-RSVP] P. Ashwood-Smith, L. Berger et al., 'Generalized MPLS 1818 Signaling - RSVP-TE Extensions,' Internet Draft, draft-ietf-mpls- 1819 generalized-rsvp-te-05.txt, October 2001. 1821 6. [GMPLS-SIG] P. Ashwood-Smith, L. Berger et al., 'Generalized MPLS 1822 Signaling - Signaling Functional Requirements,' Internet Draft, 1823 draft-ietf-mpls-generalized-signaling-06, October 2001. 1825 7. [GMPLS-BUNDLE] K. Kompella et al., 'Link Bundling in MPLS Traffic 1826 Engineering,' Internet Draft, draft-kompella-mpls-bundle-05.txt, 1827 March 2001. 1829 8. [IPO-OAPS] D.Guo, D. Papadimitriou et al., 'Optical Automatic 1830 Protection Switching - An IP-based Protocol', Work in Progress, 1831 draft-guo-optical-aps-00.txt, November 2001. 1833 9. [IPO-BUNDLE] B. Rajagopalan et al., 'Link Bundling in Optical 1834 Networks,' Internet Draft, draft-rs-optical-bundling-01.txt, 1835 November 2000. 1837 10. [IPO-FRAME] B. Rajagopalan et al., 'IP over Optical Networks: A 1838 Framework,' Internet Draft, draft-ietf-ip-optical-framework- 1839 00.txt, July 2001. 1841 11. [IPO-MPLS] D. Awduche et al., 'Multi-Protocol Lambda Switching: 1842 Combining MPLS Traffic Engineering Control With Optical 1843 Crossconnects,' Internet Draft, draft-awduche-mpls-te-optical- 1844 03.txt, April 2001. 1846 Papadimitriou D. - Internet Draft - Expires May 2002 35 1847 12. [IPO-MULT] D. Papadimitriou et al., 'Optical Multicast - An 1848 Architectural Framework,' Internet Draft, draft-poj-optical- 1849 multicast-02.txt, November 2001. 1851 13. [IPO-POES] D. Papadimitriou et al., 'Packet-Optical Escalation 1852 Strategies,' Internet Draft, draft-pbh-packet-optical-escalation- 1853 01.txt, May 2001. 1855 14. [IPO-REST] J. Hahm et al., 'Restoration Mechanisms and Signaling 1856 in Optical Networks,' Internet Draft, draft-many-optical- 1857 restoration-02.txt, February 2001. 1859 15. [IPO-RFRM] N. Ghani et al., 'Architectural Framework for 1860 Automatic Protection Provisioning In Dynamic Optical Rings,' 1861 Internet Draft, draft-ghani-optical-rings-01.txt, March 2001. 1863 16. [IPO-OMR] D. Guo et al, 'Hybrid Mesh-Ring Optical Networks,' 1864 Internet Draft, draft-guo-optical-mesh-rings, January 2001. 1866 17. [IPO-SRLG] D. Papadimitriou et al., 'Inference of Shared Risk 1867 Link Groups,' Internet Draft, draft-many-inference-srlg-02.txt, 1868 November 2001. 1870 18. [LMP] J. Lang et al., 'Link Management Protocol (LMP) v1.0', 1871 Internet Draft, Work in progress, draft-ietf-ccamp-lmp-02.txt, 1872 October 2001. 1874 19. [LMP-WDM] A. Fredette et al., 'Link Management Protocol (LMP) 1875 for WDM Transmission Systems,' Internet Draft, draft-fredette- 1876 lmp-wdm-02.txt, July 2001. 1878 20. [MPLS-CRLDP] B. Jamoussi et al., 'Constraint-Based LDP Setup 1879 using LDP,' Internet Draft, draft-ietf-mpls-cr-ldp-05.txt, 1880 March 2001. 1882 21. [OPT-MWS] T. Stern and K. Bala, 'Multiwavelength Optical Network 1883 - A Layered Approach,' Addison Wesley Longman, Inc, May 1999. 1885 22. [OPT-RINGS] G. Ellinas et al, 'Protection Cycles in Mesh WDM 1886 Networks,' IEEE Journal on Selected Areas in Communications, 1887 Volume 18, Number 10, October 2000. 1889 23. [OSPF-TE] D. Katz and D. Yeung, "Traffic Engineering Extensions 1890 to OSPF,' Internet Draft, draft-katz-yeung-ospf-traffic-06.txt, 1891 September 2001. 1893 24. [OSPF-IRTE] S. Venkatachalam et al, 'OSPF Extensions to Support 1894 Inter-Area Traffic Engineering,' Internet draft, draft- 1895 venkatachalam-ospf-traffic-00.txt, November 2000. 1897 25. [RFC2328] J. Moy, 'OSPF Version 2,' Internet RFC - Standard 1898 Track, April 1998. 1900 Papadimitriou D. - Internet Draft - Expires May 2002 36 1901 26. [RFC2370] R. Coltun, 'The OSPF Opaque LSA Option,' Internet RFC 1902 2370 - Standard Track, July 1998. 1904 27. [SPT-DYN] P. Narvaez et al., 'New Dynamic Algorithms for Shortest 1905 Path Tree Computation,' IEEE/ACM Transactions on Networking, 1906 Volume 8, Number 6, December 2000. 1908 10. Acknowledgments 1910 The authors would like to be thank Bernard Sales, Emmanuel Desmet, 1911 Hans De Neve, Fabrice Poppe, Stefan Ansorge, Katrien Skerra, Mathieu 1912 Garnot, Gert Grammel and Jim Jones for their constructive comments, 1913 suggestions and inputs. 1915 11. Author's Addresses 1917 Dimitri Papadimitriou 1918 Alcatel 1919 Francis Wellesplein 1, 1920 B-2018 Antwerpen, Belgium 1921 Phone: +32 3 240-84-91 1922 Email: Dimitri.Papadimitriou@alcatel.be 1924 Papadimitriou D. - Internet Draft - Expires May 2002 37 1925 Full Copyright Statement 1927 "Copyright (C) The Internet Society (date). All Rights Reserved. This 1928 document and translations of it may be copied and furnished to 1929 others, and derivative works that comment on or otherwise explain it 1930 or assist in its implementation may be prepared, copied, published 1931 and distributed, in whole or in part, without restriction of any 1932 kind, provided that the above copyright notice and this paragraph are 1933 included on all such copies and derivative works. However, this 1934 document itself may not be modified in any way, such as by removing 1935 the copyright notice or references to the Internet Society or other 1936 Internet organizations, except as needed for the purpose of 1937 developing Internet standards in which case the procedures for 1938 copyrights defined in the Internet Standards process must be 1939 followed, or as required to translate it into languages other than 1940 English. 1942 The limited permissions granted above are perpetual and will not be 1943 revoked by the Internet Society or its successors or assigns. 1945 This document and the information contained herein is provided on an 1946 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1947 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1948 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1949 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1950 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1952 Papadimitriou D. - Internet Draft - Expires May 2002 38