idnits 2.17.1 draft-papadim-ipo-impairments-crosstalk-00.txt: ** The Abstract section seems to be numbered -(82): 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 == There are 11 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([IPO-IMP], [ITC-DIL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8197 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 18 -- Looks like a reference, but probably isn't: '2' on line 59 == Missing Reference: 'Goldstein94' is mentioned on line 74, but not defined == Missing Reference: 'ISIS' is mentioned on line 364, but not defined == Missing Reference: 'OSPF' is mentioned on line 364, but not defined == Unused Reference: 'GYS-XT' is defined on line 380, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AGR-FOCS' -- Possible downref: Non-RFC (?) normative reference: ref. 'GYS-XT' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITC-DIL' == Outdated reference: A later version (-05) exists of draft-ietf-ipo-impairments-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ipo-impairments (ref. 'IPO-IMP') -- Possible downref: Normative reference to a draft: ref. 'IPO-NLI' -- Possible downref: Normative reference to a draft: ref. 'IPO-ORI' -- Possible downref: Non-RFC (?) normative reference: ref. 'OFC-XTD' Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPO Working Group D.Papadimitriou 3 Category: Internet Draft O.Audouin 4 Document: draft-papadim-ipo-impairments-crosstalk-00.txt J.-P.Faure 5 Expiration: May 2002 L.Noirie 6 Alcatel 8 November 2001 10 Linear Crosstalk for Impairment-based Optical Routing 12 draft-papadim-ipo-impairments-crosstalk-00.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026 [1]. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 1. Abstract 35 Optical in-band crosstalk between interfering optical channels has 36 been identified (see [ITC-DIL]) as one of the major limitations to 37 the diameter and the performance of photonic (or all-optical) 38 networks. In this context in-band crosstalk remains a cause of 39 optical signal degradation in switching elements included in a 40 Photonic Cross-Connect (PXC). 42 The aim of this draft is to extend the previous work dedicated to 43 routing impairments [IPO-IMP]. It seeks to determine which are the 44 additional linear crosstalk effects that need to be considered and 45 which kind of engineering rules may be used to take these effects 46 into account in constraint-based optical routing. 48 Moreover, we propose to introduce IGP routing protocol extensions to 49 transport information related to linear crosstalk relevant for 50 wavelength routing decisions (i.e. the route of the wavelength 51 throughout the optical network). 53 D.Papadimitriou et al. - Internet Draft Expires May 2002 1 54 2. Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 58 this document are to be interpreted as described in RFC-2119 [2]. 60 3. Introduction 62 [IPO-IMP] states that Optical crosstalk refers to the effect of 63 other signals on the desired signal. It includes both coherent (i.e. 64 intrachannel) crosstalk and incoherent (i.e. interchannel) 65 crosstalk. Main contributors of crosstalk are the OADM and OXC sites 66 that use a DWDM multiplexer/demultiplexer (MUX/DEMUX) pair. For a 67 relatively sparse network where the number of OADM/OXC nodes on a 68 path is low, crosstalk can be treated with a low margin in OSNR 69 without being a binding constraint. But for some relatively dense 70 networks where crosstalk might become a binding constraint, one 71 needs to propagate the per-link crosstalk information to make sure 72 that the end-to-end crosstalk which is the sum of the crosstalks on 73 all the corresponding links to be within some limit, e.g. 25dB 74 threshold with 1dB penalty ([Goldstein94]). Another way to treat it 75 without having to propagate per-link crosstalk information is to 76 have the system evaluate what the maximum number of OADM/OXC nodes 77 that has a MUX/DEMUX pair for the worst route in the transparent 78 domain for a low built-in margin. The latter one should work well 79 where all the OXC/OADM nodes have similar level of crosstalk.� 81 While the above description proposes alternatives to overcome 82 crosstalk impairments in all-optical environment, it doesn�t propose 83 a clear method to process this information in the context of 84 constraint-based wavelength route computation, selection and 85 allocation. 87 The corresponding conclusion expressed in [IPO-IMP] is 'Crosstalk 88 and effective passband narrowing due to filtering effects can be 89 treated approximately as a constraint on the maximum allowable 90 number of Optical Add-Drop Multiplexers (OADMs) and Photonic Cross- 91 Connects (PXCs) in the transparent segment of the lightpath or 92 optical channel.' 94 Therefore, the aim of this memo is to provide a definition for the 95 crosstalk constraint and to propose an efficient way to take these 96 effects into account for dynamic constraint-based routing in 97 Wavelength Switched (all-)optical Networks (WSoNs). 99 In WSoNs, unicast connections carried on lightpaths are optical 100 point-to-point connections between two nodes. Such connection can 101 span one or more network nodes and is used to transport packets or 102 TDM circuits from source node (ingress) to destination node 103 (egress). The network nodes can be Optical Cross-Connects (OXC) with 104 non-transparent O-E-O interfaces or Photonic Cross-Connects (PXC) 105 with transparent interfaces. PXCs do not perform any conversion of 107 D.Papadimitriou et al. Internet Draft Expires May 2002 2 108 the optical signal into the electrical domain or vice-versa (such 109 devices are also referred to as All-Optical Cross-Connects). Optical 110 networks comprised of OXCs only are referred to as 'non-transparent' 111 WsoNs, while networks built of PXCs only are known as 'all-optical' 112 or 'transparent' WSoNs. 114 In WSoNs spanning a large geographical area, an optical signal (the 115 wavelength) may traverse a number of intermediate nodes and long 116 fiber segments. In order to enable the signal to flow over the 117 desired wavelength in the optical domain, each intermediate PXC uses 118 passive and lossy switching elements (i.e., power leaking due to 119 isolation) using active electrical control mechanisms. 121 The progressive losses experienced by the signal in all these nodes 122 and long fiber segments necessitate the use of optical amplifiers 123 (usually, erbium-doped fiber amplifiers (EDFAs) or Raman amplifiers) 124 at strategic locations in the network, possibly at each node and 125 within the fiber segments. 127 Unfortunately, the PXCs and EDFAs, while offering transparent 128 switching and loss compensation respectively for optical signals, 129 may introduce significant transmission impairments, such as: 130 - in-band crosstalk generation when two or more optical signals 131 propagate through the same PXC 132 - generation of Amplifier Spontaneous Emission (ASE) noise in EDFAs 133 while providing signal amplification and wavelength dependence of 134 EDFA gain 136 These impairments, in the absolute sense, make the optical signal 137 power gain a traffic-dependent and non-deterministic quantity. The 138 in-band crosstalk and the ASE noise, generated at every intermediate 139 node, propagate along with the optical signal over the assigned 140 carrier wavelength; and all of them undergo variable gains at 141 various wavelengths because of the traffic-dependent, non flat gain 142 spectra of EDFAs. 144 Thus, a signal degrades in quality as it traverses through switches 145 and fiber segments while propagating along its assigned lightpath 146 toward its destination, and the OSNR continues to decrease. When the 147 signal finally arrives at the destination, the crosstalk and ASE 148 noise that have accumulated along with the signal may result in 149 significant degradation of the OSNR, which in turn might increase 150 the receiver bit error rate (BER) beyond its acceptable threshold. 152 In order to examine the reliability of the physical layer, one needs 153 to capture all of these physical-layer limitations together and 154 evaluate the achievable BER for a given lightpath. 156 Note: considerations related to ASE noise are fully detailed in 157 [IPO-IMP] 159 D.Papadimitriou et al. Internet Draft Expires May 2002 3 160 4. Linear crosstalk 162 In addition to non-linear crosstalk (described in [IPO-NLI]), some 163 crosstalk occurs even in a perfectly linear optical channel because 164 of the imperfect nature of various optical components such as 165 filters, demultiplexers, and switches. 167 4.1 Out-of-band crosstalk 169 Out-of-band crosstalk (also referred to as hetero-wavelength 170 crosstalk) results from the leak of a fraction of the optical signal 171 power from neighboring channels that interferes with the detection 172 process in optical filters and demultiplexers. 174 To maintain a given value of the Bit Error Rate (BER), the 175 corresponding power penalty must be kept below a certain threshold. 176 For instance, the power penalty can be limited around 0.3 dB when 177 maintaining a BER of 10^(-12) and 0.2 dB when maintaining a BER of 178 10^(-9). Notice that this threshold is dependent on the refinement 179 of the filter. 181 The out-of-band crosstalk induces at the receiver side a penalty on 182 the required power to maintain a given value of the BER. The 183 specification of a maximum acceptable penalty gives a maximum 184 admissible crosstalk value. Moreover, the out-of-band crosstalk can 185 always be further reduced at the receiver side using an enhanced 186 filtering. 188 However, this technique can not be applied to the in-band crosstalk. 189 Consequently, in-band crosstalk is a critical parameter to be taken 190 into account as impairment in constraint-based optical routing. 192 4.2 In-band crosstalk 194 In-band crosstalk (also referred to as homo-wavelength crosstalk) 195 occurs during the switching of the optical signal in multiple 196 devices such as PXCs, including (N x N) spatial switches. The in- 197 band crosstalk for a given lightpath in the (N x N) switch is 198 induced by the (N - 1) other lightpaths carried over the same 199 wavelength due to the loss of the switch. 201 Note that the out-of-band crosstalk may be transformed into in-band 202 crosstalk in a PXC, when multiplexing optical signals coming from 203 different demultiplexers through a switching stage. 205 By definition (ITU-T G.692), the optical crosstalk is defined as the 206 ratio of the combined total disturbing power due to signal power 207 from all other channels, operating under all specified conditions, 208 relative to the nominal signal power level in the desired channel, 209 at the single-channel signal output reference points SD1 ... SDn 210 according to Figure 1 (in G.692), within the resulting bandwidth of 211 the optical demultiplexer and optical receiver, expressed in dB. 213 D.Papadimitriou et al. Internet Draft Expires May 2002 4 214 Therefore, the in-band crosstalk induced by an (N x N) switching 215 element can be formulated as the fraction F (also referred to as the 216 crosstalk level) of power leaking through the switch. When assuming 217 equal power for all (N - 1) sources of coherent in-band crosstalk 218 (due to the incomplete filtering caused by the partial overlap among 219 the N channels), this leads to the r^2 factor: r^2 = F x (N - 1); 220 where r^2 is defined as an intensive noise. 222 Notice that this formulation of the induced in-band crosstalk 223 reflects an ideal system where each of the N sources provides the 224 same contribution to the in-band crosstalk. 226 As described in [AGR-FOCS], the impact of the in-band crosstalk on 227 the system performance can be evaluated by using the power penalty. 228 When the in-band crosstalk is treated as an intensive noise, the 229 power penalty D can be expressed as follows: 231 D = - 10 log (1 - (r x Q)^2) where Q is the Q factor 233 For instance, to keep the power penalty below 2dB when the Q factor 234 = 8.6, the factor r must be such that r < 0.07, thus limiting the 235 crosstalk level below �23dB when N = 2, below -36dB when N = 16 and 236 -43dB when N = 100. Alternatively, giving a power penalty of 1dB 237 (2dB) and a Q factor = 7 (BER = 10^(-12)), the crosstalk level must 238 be maintained below -24dB (-21dB respectively). 240 Note: this memo considers only first order crosstalk, i.e., the 241 crosstalk flowing through propagating in the downstream direction 242 (from ingress to egress) and producing in its turn additional 243 crosstalk or higher order crosstalk) is not considered in this 244 memo.. 246 However, the above formula is only valid when there is no optical 247 noise within the system as detailed in [OFC-XTD]. It is demonstrated 248 therein that the power penalty simulated and experimentally measured 249 depends on the optical noise: a 1dB penalty for a low OSNR value 250 induced -30dB crosstalk compared to the -24dB crosstalk without 251 optical noise. 253 5. Impact on optical routing 255 This section describes the impact of in-band crosstalk on optical 256 routing. 258 5.1 Crosstalk computation for an optical channel 260 Considering the establishment of an optical channel within a 261 network, this channel will be a succession of �j� different 262 switching elements, each switching element (SE) having a XT(SE). 264 Then, the total cumulated crosstalk over the whole optical channel 265 or path, XT(path), is given by: 267 D.Papadimitriou et al. Internet Draft Expires May 2002 5 268 XT(path) = Sum(XT(SE)[j]) 270 where XT(SE)[j] is the XT induced by the switching element 'j' 272 With this simple formula, it is possible to compute the total 273 cumulated XT for any optical channel switched through a sequence of 274 S switching elements. 276 If the (N x N) switch element is composed of n x (M x M) switching 277 sub-elements (M < N) then simply XT(SE) = Sum(XT(SSE)[i]), where 278 XT(SSE)[i] is the XT induced by the switching sub-element 'i'. 280 However, in real systems, the individual XT(SSE) values will be 281 difficult to measure; this aspect is not considered in the remaining 282 sections of this document. 284 5.3 Crosstalk constraint 286 In Section 4, we have demonstrated that the crosstalk is an additive 287 variable along an optical path (including several nodes) which 288 depends on the Q factor and the channel spacing (more precisely the 289 number of channels). Therefore, the cumulative XT value over the 290 whole optical path (XT(path)) can be used to determine the maximum 291 number of hops (i.e., PXCs) that this channel can traverse. 293 Consequently, the crosstalk routing constraint can be expressed as 294 follows: after switching an optical channel through a sequence of 295 PXCs the total cumulative crosstalk XT(path) must be such that: 297 - 10 log (1 - Q^2 x XT(path)) < D 299 When XT(path) fulfills this constraint, the corresponding optical 300 channel is not limited by the in-band crosstalk induced by the 301 switching elements of the PXCs along the optical path (though 302 depending on the OSNR). This suggests a limiting D factor compatible 303 with the OSNR margin. Using a conservative value for the power 304 penalty limit guarantees the feasibility of the optical channel in 305 the worst OSNR case; however, this will lead to reject some feasible 306 paths. 308 Therefore, by applying the above formula which does not take into 309 account OSNR effects, when the Q factor is known and using D as a 310 constraint (usually 1 or 2dB power penalty), one can determine with 311 the above formula the maximum number of switching elements (and 312 subsequently the maximum number of PXCs) that a given optical 313 channel can traverse. 315 Another approach would be to have a table, based on measurements or 316 simulations, giving the different XTmax values as a function of the 317 targeted Q (since a single Q value could not be sufficient for all 318 optical channels when providing QoS differentiation for instance) 319 and cumulative OSNR per channel (OSNR(path)). XT(path) would then be 321 D.Papadimitriou et al. Internet Draft Expires May 2002 6 322 compared to the proper XTmax retrieved from this table. As such, 323 this approach works without any complex formula. 325 Remember also that any PXC will be designed to limit as much as 326 possible the in-band crosstalk. 328 6. Traffic-engineering routing protocol extension 330 Using the approach initiated in [IPO-ORI], the in-band crosstalk 331 constraint can be integrated into the OSPF-TE Link-State 332 Advertisement (LSA) or ISIS-TE Link State PDU (LSP). As mentioned 333 here above, the XT(SE) parameter may be flooded using a dedicated 334 extension to the Router TLV defined for IGP TE-Routing protocol. 336 In OSPF, this XT(SE) parameter is included in a common sub-TLV of 337 the Router TLV in the Traffic Engineering LSA since this parameter 338 defines a node (and not a link) TE attribute. The Type value of this 339 sub-TLV is to be attributed (TBA). The length of this sub-TLV is 4 340 octets and the corresponding value specifies the XT(SE) value (in 341 IEEE floating point format) per switching element. The format of the 342 XT(SE) sub-TLV is shown below: 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Type = TBA | Length = 4 | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | XT(SE) | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 In IS-IS, the XT(SE) parameter is included in a sub-TLV (whose type 353 is TBA) of the Traffic Engineering router ID TLV (type 134). The 354 length of this sub-TLV is 4 octets and the corresponding value 355 specifies the XT(SE) value (in IEEE floating point format) per 356 switching element. More precisely, the following sub-TLV is added: 357 - Sub-TLV type: TBA 358 - Length (in bytes): 4 359 - Name: XT(SE) 361 7. Security Considerations 363 This memo does not imply additional security issues than the one 364 considered in [ISIS] and [OSPF]. 366 8. References 368 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 369 9, RFC 2026, October 1996. 371 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 372 Levels", BCP 14, RFC 2119, March 1997. 374 3. [AGR-FOCS] Govind P. Agrawal, �Fiber-Optic Communication 376 D.Papadimitriou et al. Internet Draft Expires May 2002 7 377 Systems�, Second Edition, Wiley Series in Microwave and Optical 378 Engineering, March 1997. 380 4. [GYS-XT] T. Gyselings, �Investigation and Reduction of CrossTalk 381 in Wavelength Division Multiplexed All-Optical Cross-Connects�, 382 PhD Thesis, INTEC, Universiteit Gent. 384 5. [ITC-DIL] K. Padmanabhan and A.N. Nevrali, �Dilated networks for 385 photonic switching�, IEEE Trans. Commun., Vol.35, pp 1357-1356, 386 Dec. 1987. 388 6. [IPO-IMP] A. Chiu et al., 'Impairments and Other Constraints On 389 Optical Layer Routing', Internet Draft, Work in progress, draft- 390 ietf-ipo-impairments-00.txt, May 2001. 392 7. [IPO-NLI] D. Papadimitriou et al. 'Non-linear Routing Impairments 393 in Wavelength Switched Optical Networks', Internet Draft, Work in 394 Progress, draft-papadimitriou-ipo-non-linear-routing-impairm- 395 01.txt, November 2001. 397 8. [IPO-ORI] A. Banerjee et al., 'Impairment Constraints for Routing 398 in All-Optical Networks', Internet Draft, Work in progress, 399 draft-banerjee-routing-impairments-00.txt, May 2001. 401 9. [OFC-XTD] L. Noirie et al., 'Crosstalk-induced degradation in an 402 optical-noise-limited detection system', Paper presented during 403 OFC�99, TuR4, San Diego, USA, 21-26 February 1999. 405 10. Acknowledgments 407 The authors would like to thank B.Sales and E.Desmet for their 408 constructive comments and inputs. 410 11. Author's Addresses 412 Dimitri Papadimitriou 413 Alcatel 414 Francis Wellesplein 1, 415 B-2018 Antwerpen, Belgium 416 Phone: +32 3 240-8491 417 Email: dimitri.papadimitriou@alcatel.be 419 Jean-Paul Faure 420 Alcatel 421 Route de Nozay 422 91461 Marcoussis Cedex, France 423 Phone: +33 1 6963-1307 424 Email: jean-paul.faure@ms.alcatel.fr 426 Olivier Audouin 427 Alcatel 428 Route de Nozay 429 91461 Marcoussis Cedex, France 431 D.Papadimitriou et al. Internet Draft Expires May 2002 8 432 Phone: +33 1 6963-2365 433 Email: olivier.audouin@ms.alcatel.fr 435 Ludovic Noirie 436 Alcatel 437 Route de Nozay 438 91461 Marcoussis Cedex, France 439 Phone: +33 1 6963-3476 440 Email: ludovic.noirie@ms.alcatel.fr 442 D.Papadimitriou et al. Internet Draft Expires May 2002 9 443 Full Copyright Statement 445 "Copyright (C) The Internet Society (date). All Rights Reserved. 446 This document and translations of it may be copied and furnished to 447 others, and derivative works that comment on or otherwise explain it 448 or assist in its implementation may be prepared, copied, published 449 and distributed, in whole or in part, without restriction of any 450 kind, provided that the above copyright notice and this paragraph 451 are included on all such copies and derivative works. However, this 452 document itself may not be modified in any way, such as by removing 453 the copyright notice or references to the Internet Society or other 454 Internet organizations, except as needed for the purpose of 455 developing Internet standards in which case the procedures for 456 copyrights defined in the Internet Standards process must be 457 followed, or as required to translate it into languages other than 458 English. The limited permissions granted above are perpetual and 459 will not be revoked by the Internet Society or its successors or 460 assigns. 462 This document and the information contained herein is provided on an 463 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 464 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 465 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 466 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 467 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 469 D.Papadimitriou et al. Internet Draft Expires May 2002 10