idnits 2.17.1 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt: ** The Abstract section seems to be numbered -(741): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(834): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1054): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1058): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1067): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1087): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1269): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1284): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 44 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 24) being 65 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 ([LMP-WDM], [LMP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 189 has weird spacing: '...nnected throu...' == Line 343 has weird spacing: '...2 Trace patte...' == Line 878 has weird spacing: '...is that the L...' == Line 928 has weird spacing: '... former to de...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 2002) is 7826 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 19 -- Looks like a reference, but probably isn't: '2' on line 53 == Missing Reference: 'GMPLS-OTN' is mentioned on line 297, but not defined == Missing Reference: 'ITUT-G664' is mentioned on line 453, but not defined == Missing Reference: 'ITUT-G783' is mentioned on line 454, but not defined == Missing Reference: 'RFC-1662' is mentioned on line 595, but not defined == Missing Reference: 'RFC-2615' is mentioned on line 596, but not defined == Missing Reference: 'CCAMP-OLI' is mentioned on line 823, but not defined == Missing Reference: 'OLI' is mentioned on line 831, but not defined == Unused Reference: 'GMPLS-LDP' is defined on line 1050, but no explicit reference was found in the text == Unused Reference: 'GMPLS-RSVP' is defined on line 1054, but no explicit reference was found in the text == Unused Reference: 'MPLS-BUND' is defined on line 1091, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 1099, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1102, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-gmpls-architecture-03 == Outdated reference: A later version (-08) exists of draft-ietf-ccamp-gmpls-sonet-sdh-07 == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-lmp-06 -- Unexpected draft version: The latest known version of draft-ansorge-ccamp-lmp-sonet-sdh is -00, but you're referring to -01. -- No information found for draft-ietf-ccamp-lmp-sonet-sdh - is the name correct? == Outdated reference: A later version (-03) exists of draft-lang-ccamp-lmp-bootstrap-01 == Outdated reference: A later version (-03) exists of draft-ietf-ccamp-lmp-wdm-01 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in 'RFC2026'. Summary: 7 errors (**), 0 flaws (~~), 25 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group W. Bigos (AGH) 3 Internet Draft S. Ansorge (Alcatel) 4 Category: Informational G. Grammel (Alcatel) 5 Expiration Date: May 2003 F. Tetzlaff (T-Systems) 6 D. Papadimitriou (Alcatel) 7 F.-J. Westphal (T-systems) 9 November 2002 11 Applicability of LMP (and LMP-WDM) 13 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026 [1]. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 1. Abstract 37 Integration of Generalized MPLS-capable SONET/SDH networks in 38 existing backbone environments has generated the need to determine 39 inter-working capabilities between nodes interconnected by both 40 SONET/SDH and non-SONET/SDH overhead terminating networks. This is 41 particularly the case for critical functions and applications such 42 as the ones provided by the Link Management Protocol [LMP] and its 43 WDM extensions [LMP-WDM]. In this context, this document describes 44 the applicability of their respective functions and illustrates them 45 through several inter-connection architectures. 47 D.Papadimitriou et al. Expires May 2003 1 48 2. Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 52 this document are to be interpreted as described in RFC-2119 [2]. 54 In addition the reader is expected to be familiar with the 55 terminology described in [LMP], [LMP-WDM] and [GMPLS-SIG]. 57 3. Introduction 59 Today nearly all regional-, metro- and backbone transmission 60 networks are equipped with SONET/SDH devices. These networks are 61 managed by manual operations via a centralized management system. 62 Most of the current SONET/SDH devices do either not provide the 63 required capability for GMPLS to operate (also referred to as legacy 64 SONET/SDH nodes) or are not capable to support the GMPLS protocol 65 set required to act as LSRs (also referred to as GMPLS-capable 66 nodes). One migration scenario for the near future may consist out 67 of a small GMPLS capable sub-network which is initially build out of 68 a few GMPLS capable nodes only and the GMPLS-capable nodes are 69 interconnected via manually established connections over a legacy 70 SONET/SDH sub-network. The operation and maintenance in legacy 71 SONET/SDH environments are well defined as well as their interaction 72 with the management plane. For the GMPLS-capable nodes exist the 73 Link Management Protocol [LMP] and appropriate enhancements like the 74 ones proposed in [LMP-SONET-SDH-TEST] and [LMP-SONET-SDH]. The 75 missing link is the communication between and across both sub- 76 networks. 78 This document proposes LMP (and LMP-WDM) as the protocol for 79 communicating information between and across non-LMP capable and 80 LMP-capable device(s). In turn, this enables to build a logical 81 GMPLS network on top of existing legacy environments and to fulfill 82 the requirements of different migration scenarios. 84 The Link Management Protocol [LMP] is being developed as part of the 85 GMPLS protocol suite to manage traffic engineering (TE) links. LMP 86 currently consists of four main functions, of which, the first two 87 functions are mandatory and the last two are optional: 89 1. Control channel management 90 2. Link property correlation 91 3. Link verification 92 4. Fault management 94 Control channel management is used to establish and maintain IP 95 connectivity between adjacent nodes. This is done using a Config 96 message exchange followed by a lightweight keep-alive message 97 exchange. Link property correlation is used to aggregate multiple 98 data links into a single TE Link and to synchronize the link 99 properties. Link verification is used to verify the physical 100 connectivity of the data links and to exchange the data link Ids. 102 D.Papadimitriou et al. Expires May 2003 2 103 Fault management is used to localize failure points and consequently 104 suppress alarms on subsequent points in both opaque and transparent 105 networks. 107 In [LMP-SONET-SDH], [LMP-SONET-SDH-TEST] and [LMP-BOOT], we define 108 SONET/SDH technology specific information needed when running LMP. 109 Specifically, we define the SONET/SDH test procedures used for Link 110 and LSP verification and link property correlation. We also propose 111 a Link verification procedure using loopback capable SONET/SDH 112 interface. 114 This document describes two generic SONET/SDH node inter-connection 115 cases and the applicability of LMP between these edge devices. In 116 the first case (described in Sections 4), LMP-capable SONET/SDH edge 117 devices are connected by a legacy SONET/SDH network that terminates 118 the section overhead and none of its node is LMP-capable (the LMP 119 session is provided between the client SONET/SDH devices only). In 120 the second case (described in Section 7), the LMP (and LMP-WDM) 121 capable SONET/SDH edge devices are connected through a non-SONET/SDH 122 network that does not terminate the section overhead at its edges. 123 Moreover, one considers that the edge devices of the non-SONET/SDH 124 network are LMP-WDM capable. Several reference architectures and 125 scenarios (see Section 4) illustrate these two generic inter- 126 connection cases. From these, this document deduces (in Section 5 127 and 6) the applicability of the LMP functions and their detailed 128 operations. 130 4. Scope and Covered scenarios 132 Depending on the configuration of the underlying legacy SONET/SDH 133 network, there are many different possible migration scenarios from 134 legacy configuration to networks, which are completely GMPLS 135 capable. Some criteria to distinguish between different scenarios 136 are listed here: 137 - For protection purposes it is possible to connect two GMPLS 138 capable nodes via a protected SONET/SDH connection. . 139 - Another way is to protect the interconnection of the GMPLS 140 capable sub-network via a further interconnection within the 141 legacy sub-network, which is disjoint with the first and may be 142 selected in the case of an fault. The GMPLS capable nodes have 143 to take care about protection switching time within the legacy 144 sub-network. 145 - A further distinction could be made by SONET/SDH leased lines 146 configured with or without automatic laser shutdown. A 147 unidirectional link failure results into bi-directional link 148 failure. 149 - And finally the legacy SONET/SDH sub-networks in between the 150 GMPLS capable sub-network can be operated unidirectional or bi- 151 directional. 153 Thus this document covers 3 migration scenarios. Each of them is 154 described in detail here below: 156 D.Papadimitriou et al. Expires May 2003 3 157 Scenario 1: Reference architecture 159 LMP Network <---- --- non-LMP Sub-Network --- ---> LMP Network 160 | | 161 | | 162 | | 163 SONET/SDH Net <-- --> SONET/SDH Sub-Net <-- ---> SONET/SDH Net 164 Edge Node(X) Node(1) ---- Node(N) Edge Node(Y) 165 | | 166 | | 167 | | 168 <---------------------- LMP -----------------------> 170 Here one assumes Path OH transparency over the SONET/SDH sub- 171 network, thus the non-LMP Sub-Network includes only MS/Line (or 172 RS/section) Terminating equipment and provides only path trail 173 service. 175 The path trail between the LMP capable (GMPLS capable) SONET/SDH 176 sub-network is terminated at edge Node(X) and edge Node(Y). The 177 SONET/SDH leased line between node (1) and node (N) of the legacy 178 SONET/SDH sub-network is unprotected, without automatic laser 179 shutdown and bi-directional. The considered SONET/SDH overhead 180 information is related to the SONET/SDH path between Node(X) and 181 Node(Y). Without further restrictions it may be necessary to define 182 a kind of bundling of trails (and not links) between the LMP 183 adjacencies (Node (X) and Node (Y)). The specific aspects related to 184 trail discovery and bundling are addressed in Section 6. 186 Scenario 2 � Reference Architecture 188 This scenario can be considered as a particular case of the previous 189 one where Node(X) and Node(Y) are inter-connected through a legacy 190 SONET/SDH sub-network managed by an Element Management System (EMS). 191 In turn, this EMS represents from the edge node viewpoint, an LMP- 192 capable adjacent node hiding the non-support of LMP within the 193 legacy sub-network. 195 LMP Network <-- --- non-LMP Sub-Network --- --> LMP Network 196 | | 197 | | 198 | | 199 SONET/SDH Net <-- --> SONET/SDH Sub-Net <-- --> SONET/SDH Net 200 Edge Node(X) Node(1) ---- Node(N) Edge Node(Y) 201 | | 202 | | 203 | | 204 <---------LMP---------> EMS <--------LMP--------> 206 In such conditions, potential problem may come from the processing 207 time of the LMP messages at the EMS. This, in addition to the time 209 D.Papadimitriou et al. Expires May 2003 4 210 it takes to correlate the information received from the edge LMP 211 sessions defined between Node(X) and EMS and between EMS and 212 Node(Y), with the one received through its proprietary interface to 213 the non-LMP sub-network nodes). 215 It may thus be advisable to combine both LMP Sessions with an edge- 216 to-edge LMP session in order to achieve the following LMP 217 adjacencies and sessions: 219 LMP Network <-- --- non-LMP Sub-Network --- --> LMP Network 220 | | 221 | | 222 | | 223 SONET/SDH Net <-- --> SONET/SDH Sub-Net <-- --> SONET/SDH Net 224 Edge Node(X) Node(1) ---- Node(N) Edge Node(Y) 225 | | | | 226 | | | | 227 | <---------LMP-------> EMS <-------LMP-------> | 228 | | 229 <--------------------------LMP------------------------> 231 The purpose of this edge-to-edge LMP session (between the SONET/SDH 232 legacy sub-network edge nodes, e.g. Node(X) and Node(Y)) is somehow 233 less obvious. Here, the value added by this edge-to-edge LMP session 234 in the above architecture would (only) help to determine whether the 235 failure is located inside or outside the SONET/SDH sub-network but 236 when located inside if the defect is localized between edge nodes or 237 internal to the sub-network (i.e. between Node(1) and Node(N)). 239 Scenario 3 � Reference Architecture 241 In this architecture, one assumes that the SONET/SDH edge Node(X) 242 and Node(Y) maintain an LMP session with the edge nodes of the 243 legacy SONET/SDH sub-network through the use of an EMS system (EMS1 244 for Node(X) and EMS2 for Node(Y)). 246 However, since LMP continuity is not available between edge Node(X) 247 and Node(Y) a complementary edge-to-edge LMP session between Node(1) 248 and Node(N) should normally allow to bridge their local instances 249 with the EMS systems located at the edges. In this context, the 250 following configuration can be considered: 252 LMP Network <------ LMP Sub-Network ------> LMP Network 253 | | 254 | | 255 SONET/SDH Net <-- --> SONET/SDH Sub-Net <-- --> SONET/SDH Net 256 Edge Node(X) Node(1) -------- Node(N) Edge Node(Y) 257 | | | | | | 258 | | | | | | 259 | | | | | | 260 EMS1 <---LMP--- <----LMP----> ---LMP---> EMS2 262 D.Papadimitriou et al. Expires May 2003 5 263 Here, the Element Management System (EMS) fulfilling an LMP Proxy 264 function allows considering actions based on failure indication 265 correlated information, if the failure is external to the SONET/SDH 266 sub-network then either EMS1 or EMS2 will take the recovery decision 267 under its responsibility. However, if the failure is internal to the 268 SONET/SDH sub-network then through a dedicated message exchange 269 between Node(1) and EMS1 (or between Node(N) and EMS2) the recovery 270 action could still be initiated by EMS1 (or EMS2) and executed by 271 the edge nodes Node(X) (or Node(Y), respectively). 273 Note: (LMP) Control Channel 274 --------------------------- 276 In the SONET/SDH context, two signalling transport mechanisms are 277 defined: out-of-band or in-band through the RS/Section (D1-D3) and 278 MS/Line DCC (D4-D12) � note for OC-768 (D13-D156 is also defined) 280 Therefore, due to the termination of the MS/Line and RS/Section at 281 the legacy sub-network SONET/SDH nodes, one should preferably 282 consider an out-of-band control channel. This because having an in- 283 band control channel would imply maintaining an (LMP) control 284 channel using the Data Communication Channel (DCC) bytes and some 285 overhead mapping facilities to allow forwarding DCC information 286 between neighbouring RS/Section and MS/Line trails. 288 5. Fault Localization 290 Fault Management, includes Fault Detection, Fault Correlation and 291 Fault Localization/Isolation. [LMP] provides the tools to deliver 292 the Fault Localization/Isolation capabilities. However, he challenge 293 compared to the canonical LMP model is that a node adjacency does 294 not give a corresponding LMP adjacency. 296 Moreover, labels have an associated structure relying on their 297 multiplexing structure (see [GMPLS-SONET-SDH] and [GMPLS-OTN]). Once 298 the local label is exchanged across an interface to its neighboring 299 node, the value of the local label may be not significant to the 300 neighbor node since the value used for the local label and the 301 remote label may not necessarily be the same. This issue does not 302 present a problem in a simple connection between adjacent nodes the 303 timeslots are mapped 1:1 across the interface. However, once a non- 304 GMPLS capable sub-network is introduced between these nodes (as in 305 the above figure, where the sub-network provides re-arrangement 306 capability for the timeslots) label association becomes an issue. 308 These observations generate the following issues with respect to 309 LMP: 311 1. Fault correlation must be provided between non-physically 312 adjacent LMP neighbors 313 2. Links are not anymore symmetrical (the labels on an egress 314 interface of the edge Node(X) are not necessarily the same at the 315 ingress interface of the edge Node(Y) and vice versa) 317 D.Papadimitriou et al. Expires May 2003 6 318 To enable fault correlation and isolation/localization between non- 319 physically adjacent LMP neighbors the complete defect indication 320 flows considered here can be summarized as follows when a 321 unidirectional failure occurs: 323 Node(X) <------- Subnet -------> Node(Y) 325 Node(X) FDI ---------> Node(Y) - Forward DI (downstream) 326 | 327 Node(X) <-------- BDI ---------- Node(Y) � Backward DI (upstream) 329 DI is used as a generic term to indicate a Defect indication (such 330 as LoF, LoP or LoM depending upon the connectivity or continuity, 331 supervision respectively). See Appendix 1 for the SONET/SDH 332 Supervision Capabilities. The FDI is used as a generic term and 333 refers to the Alarm Indication Signal (AIS), AIS is a signal sent 334 downstream as an indication that an upstream defect has been 335 detected. The BDI is used as a generic term and refers to the Remote 336 Defect Indication (RDI). RDI is a signal sent upstream as an 337 indication to the remote transmit end that the received end has 338 detected an incoming trail defect or is receiving AIS. 340 The first action to be executed between Node(X) and Node(Y) is to 341 obtain the interface ID mapping (and label association), for this 342 purpose one expects here to see the capability for these node to 343 insert a J1/J2 Trace pattern sent in-band to be correlated with an 344 out-of-band test message as described in [LMP-SONET-SDH]. 346 Then, in order to locate the failure event, one takes advantage of 347 the Fault isolation/localization capabilities of [LMP], which can be 348 briefly summarized through the following flow diagram: 350 Tx ----------------> Rx 351 Node(i) Node(j) 352 Rx <---------------- Tx 354 1. Failure detected at Node(j) Receiver (Rx) side 355 2. ChannelStatus message sent from Node(j) to Node(i), the latter 356 sends an Acknowledgment message back to Node(j) upon reception 357 3. Correlation is performed at Node(i) (notice that once 358 correlation and localization is performed any subsequent recovery 359 action can be initiated) 360 4. ChannelStatus message sent from Node(i) to Node(j), upon 361 reception, the latter sends an Acknowledgment message back to 362 Node(i) 364 Here, the expected LMP behavior can be determined from the following 365 indications received from the transport plane overhead. Here below 366 we analyze the following cases: 368 D.Papadimitriou et al. Expires May 2003 7 369 Case a) Uni- or bi-directional failure within the legacy network 371 Case b) Uni- or bi-directional failure outside the legacy network 372 - Case b1) Downstream FDI 373 - Case b2) Upstream FDI 375 Case a) Uni- or Bi-directional failure within the legacy SONET/SDH 376 sub-network 378 Consider for instance that Node(Y) receives an FDI (and optionally, 379 Node(Y) sends a BDI that is subsequently received by Node(X)) and 380 wants to locate whether the failure has occurred inside or outside 381 the SONET/SDH legacy sub-network (see Section 4 - Scenario 1, for 382 instance). In this case, Node(Y) receiving the FDI sends a 383 (ChannelStatus) message to Node(X), the latter after acknowledging 384 its reception, verifies the indication received for the same trail 385 in the upstream direction (i.e. Node(X) verifies if an defect 386 indication has been on the corresponding receiver side) and in the 387 downstream direction (i.e. Node(X) checks if it has received an FDI 388 indication at one of its input ports). Then, since Node(X) has not 389 received an FDI indication at one of its incoming or outgoing 390 interfaces, the fault has been localized as uni-directional failure 391 within the legacy sub-network. In this eventuality, Node(X) can 392 perform any of the sub-sequent recovery action needed to recover the 393 trail under failure condition. Then, Node(X) sends a (ChannelStatus) 394 message to Node(Y) which acknowledges its reception. 396 So, in brief, in case of unidirectional failure, the fault isolation 397 steps are the following: 399 1. Node(Y): Send ChannelStatus message to Node(X) upon FDI reception 400 and wait for ACK 401 2. Node(X): ACK the ChannelStatus message received from Node(Y) and 402 perform correlation 403 3. Node(X): Send ChannelStatus message to Node(Y) and wait for ACK 405 This becomes more complex when a bi-directional failure occurs: 407 Node(X) <------- Subnet -------> Node(Y) 409 Node(X) FDI ---------> Node(Y) � Forward DI (downwstream) 411 Node(X) <-------- FDI Node(Y) � Forward DI (upstream) 413 Here, both Node(X) and Node(Y) sends a (ChannelStatus) message 414 toward Node(Y) and Node(X) respectively. After acknowledgment, both 415 sides correlate the FDI received at their input port, and determine 416 the bi-directionality of the failure within the legacy sub-network. 418 Thus here, the correlation will generate a (ChannelStatus) message 419 from node Node(X) to Node(Y). This message indicates the interface 420 status corresponding to the one specified by the (LMP) neighboring 422 D.Papadimitriou et al. Expires May 2003 8 423 node but also the status of the corresponding receiver interface 424 (i.e. the one through which the FDI message is received). 426 In order to prevent any further FDI (AIS) to be reported by Node(Y) 427 to a supervisory system, one assumes here that once the 428 acknowledgment (ChannelStatusAck) message is received by the sender 429 of the ChannelStatus message, alarm reporting is suppressed. 430 Moreover, taking into account that LMP will not generate any 431 subsequent (ChannelStatus) Message as long as the FDI indication is 432 received this would pace the whole process and thus avoid 433 overflowing the control plane until the interface status recovers. 435 Note: Automatic Laser Shutdown (ALS) 437 ALS can be considered as a specific case of uni-directional failure 438 generating bi-directional failure indication. Consider the following 439 situation: 441 Tx --- .. --- Rx - Tx1 ---x---> Rx2 � Tx --- .. --- Rx 442 | | 443 TE <---- FDI --- x x --- FDI ----> TE 444 | | 445 Rx --- .. --- Tx - Rx1 <--x---- Tx2 � Rx --- .. --- Tx 447 The consecutive Loss of Signal defect (dLOS) at "conventional" 448 receiver RX2 is used to shutdown the output of "conventional" 449 transmitter TX2, which is the adjacent transmitter in the opposite 450 direction. This in turn leads to dLOS in "conventional" receiver 451 Rx1, which in turn shuts down "conventional" transmitter Tx1. After 452 shutdown the output power of the transmitter shall be sufficiently 453 low to generate dLOS at the receiver side. See [ITUT-G664] for more 454 details on ALS and [ITUT-G783] for more detail on dLOS. 456 Case b) Uni- or Bi-directional failure outside the legacy SONET/SDH 457 sub-network 459 In this case, the legacy SONET/SDH only forward the defect 460 indication and therefore one can reasonable assume that Node(X) will 461 detect the same indication as Node(Y). Thus the failure is located 462 outside the SONET/SDH legacy sub-network and either an FDI or 463 optionally a BDI is detected. 465 Ingress incoming interface / Egress incoming interface 467 Case b1) Downstream FDI 469 On one hand, if Node(X) then Node(Y) receive an FDI as depicted in 470 the following figure: 472 Node(W) ----------- Node(X) ---- Subnet ----> Node(Y) 474 D.Papadimitriou et al. Expires May 2003 9 475 Node(W) --- FDI --> Node(X) ---- FDI ----> Node(Y) 477 By receiving the FDI on one of its ingress interface, Node(X) 478 follows the canonical fault localization/ correlation procedure 479 while Node(Y) by receiving the FDI transported over the legacy 480 SONET/SDH sub-network follows the procedure described here below: . 482 By receiving the ChannelStatus message from Node(Y), Node(X) 483 correlates this information received for the corresponding ingress 484 interface (flowing in the downstream direction) and egress interface 485 (flowing in the upstream direction). Since a defect indication is 486 only received at one of its ingress interfaces for the corresponding 487 trail (from Node(W)), Node(X) sends a ChannelStatus message to 488 Node(Y) indicating that the corresponding egress interface (toward 489 Node(Y)) has not received any failure indication for that trail. 490 This means that the failure is localized upstream to Node(X). 491 Therefore, neither Node(X) or Node(Y) will perform any subsequent 492 recovery actions for that trail as the failure is located upstream, 493 outside to the legacy SONET/SDH network. 495 Case b2) Upstream FDI 497 On the other hand, if Node(Y) then Node(X) receive an FDI as 498 depicted in the following figure: 500 Node(X) <--- Subnet ----- Node(Y) ----------- Node(Z) 502 Node(X) <--- FDI ----- Node(Y) <-- FDI --- Node(Z) 504 One gives the precedence to the node receiving the FDI indication, 505 however this does not provide any effective processing since from 506 one side both edge nodes will either wait for each other or send the 507 initiating fault correlation message. Thus one has to rely on the 508 ChannelStatus message sent by Node(Y) to Node(Z) and the one sent by 509 Node(X) to Node(Y). Both are triggered by the FDI indication 510 received on their egress interface that generates the above- 511 mentioned (downstream) sequence of ChannelStatus message. 513 Here, by receiving from Node(X) the ChannelStatus message, Node(Y) 514 correlates this information with the one detected at its egress 515 interface (flowing in the upstream direction). Since, a defect 516 indication has been received on one of its egress interfaces for the 517 corresponding trail but not one of its ingress interfaces. Thus, 518 Node(Y) has to rely on the ChannelStatus message sent to Node(Z) in 519 order to know where the fault is localized. In any case, Node(Y) 520 sends a ChannelStatus message to Node(X) indicating that the 521 corresponding ingress interface (toward Node(X)) has not received 522 any failure indication for that trail. This means that the failure 523 is localized downstream to Node(Y). Therefore, neither Node(X) or 524 Node(Y) will perform any subsequent recovery actions for that trail 525 as the failure is located downstream and outside to the legacy 526 SONET/SDH network. 528 D.Papadimitriou et al. Expires May 2003 10 529 6. Link Verification and Link Property Correlation 531 In LMP, the canonical Link Verification procedure assumes that any 532 link verification operation is performed before inserting the user 533 traffic. 535 In the context, Link Verification procedure is used to deliver 536 1) Interface ID Mapping and Label Association at bootstrap 537 2) Capability to verify the connectivity of a trail when not 538 transporting normal traffic 540 In the current context (for instance, scenario 1), Link Connectivity 541 Verification procedure throughout the SONET/SDH sub-network can be 542 provided by using inherent (Path) Trail Trace mechanisms, as defined 543 in [LMP-SONET-SDH]. This has to be performed on unallocated data 544 links since one can not apply Path Trail Trace capabilities of the 545 POH (J1, J2 bytes) unless the signal label (C2 byte of the POH) is 546 supervisory unequipped together with UNEQ alarm de-activation. Thus 547 one expects to perform this operation during the initial discovery 548 phase. 550 Note: using Supervisory Trail Termination (STT) function is 551 applicable when the transport plane is not carrying user traffic. In 552 this case the function generates a valid signal (at Node(X)) that 553 can be supervised from the other side (at Node(Y), for instance). 555 Moreover, one has to consider that [LMP] does not allow the exchange 556 of the SONET/SDH label in order to provide a consistent interface 557 ID/Label association between non-adjacent device�s interfaces. Thus 558 in addition to exchange of the interface ID during Link Verification 559 (see [LMP-SONET-SDH]) one foresees here the exchange of the 560 corresponding Label value (see [GMPLS-SONET-SDH]). The corresponding 561 message exchange only involves (as described in [LMP]) local 562 interface identifier exchange in such a way that provisioning of the 563 non-adjacent device corresponding values are dynamically discovered. 565 Once this interface mapping and label association is available at 566 the nodes bordering the legacy SONET/SDH network (for instance, 567 Node(X) and Node(Y)), trail bundling operation can be performed. 568 Trail bundling extends the Link Property Correlation from the 569 section to the path level allowing the grouping of path trails 570 having for instance, the same Resource Class and Traffic Engineering 571 Metric as specified in [GMPLS-ARCH]. However, one of the major 572 aspects is to define a (path) trail correlation property enabling to 573 group most (if not any) of the SONET/SDH specific path attributes 574 such as performance monitoring capabilities and (configurable) 575 thresholds for instance. 577 6.1 Discovery 579 LMP delivers transport (or data) plane independent mechanisms while 580 still allowing for specific usage of the data plane barrier 581 technology. In particular, when considering SDH or OTH data planes, 583 D.Papadimitriou et al. Expires May 2003 11 584 the transport of the Test and Bootstrap messages can be considered 585 and combined with the LMP (control plane) capabilities. In turn, 586 this enables the elaboration of discovery functions. 588 6.1.1 (Signalling) Transport Mechanisms 590 Two classes of signalling transport mechanisms are defined. The 591 first class is defined as embedded in the data plane channels (in- 592 band) and second one is dissociated from the data plane channels 593 (out-of-band). Depending on the transmission medium one gets the 594 following classes: in-band (thus in-fiber) signalling transport 595 mechanism using [RFC-1662] framing and out-of-band signalling 596 transport mechanism using [RFC-2615]. 598 On the other hand, several transport mechanisms can be considered 599 for the Test [LMP-SONET-SDH-TEST] and the Bootstrap [LMP-BOOT] 600 message exchange (in-band, by definition): 602 For Sonet/SDH data planes: 603 - Section/RS Trace (J0) 604 - STS SPE/HOVC and VT SPE/LOVC Path Trace (J1/J2) 605 - Section/RS Data Communication Channel DCC(1-3) overhead bytes 606 - Line/MS DCC(4-12) overhead bytes 608 For OTH data planes: 609 - OTUk Trail Trace Identifier (TTI) 610 - ODUk Trail Trace Identifier (TTI) 611 - OTUk General Communication Channel GCC(0) overhead bytes 612 - ODUk GCC(1/2) overhead bytes 614 6.1.2 Independence between Data and Control Plane 616 LMP Control channels exist independently of both data links and TE 617 links and multiple control channels may be active simultaneously 618 between a pair of nodes. Between these nodes, individual control 619 channels can be realized in different ways as explained here above. 620 Their configuration parameters must be negotiated over each 621 individual control channel, and LMP Hello packets must be exchanged 622 over each control channel to maintain LMP connectivity if other 623 mechanisms are not available. 625 Moreover since one assumes that the control channels are terminated 626 in the digital domain at each node, it is also possible to detect 627 control channel failures using data plane (e.g., SONET/SDH or OTH) 628 detection mechanisms. However, this method introduces a self- 629 consistence problem when using in-fiber in-band signalling transport 630 mechanism and should only be used in combination with LMP Hellos to 631 detect neighboring node failure. 633 6.1.3 (Auto-)Discovery 635 Discovery of the neighboring nodes� interfaces consists in finding 636 the mapping between local interface_id and the remote interface_id. 638 D.Papadimitriou et al. Expires May 2003 12 639 Thus, this is simply referred to as data link discovery. On the 640 other hand, auto-discovery provides additionally the dynamic setup 641 of the control channel through which this information will be 642 exchanged (thus at the control plane level). Therefore, auto- 643 discovery joins discovery of the data plane interface_id (and their 644 correlation) with the automated establishment of the control 645 channels (also referred to as control channel bootstrapping). On the 646 contrary discovery implies the a-priori (static) configuration of 647 the control channels between the neighboring nodes. 649 1. Discovery 651 Discovery (of the data links) implies the previous setup of (at 652 least one) bi-directional control channel with the neighboring node 653 with which the link verification procedure will be initiated. The 654 link verification procedure thanks to its negotiation phase of the 655 transport mechanism to be used for the exchange of Test messages 656 (see [LMP-SONET-SDH-TEST]) allows for interface_id mapping discovery 657 (i.e. common knowledge of the data link identifier pair). These data 658 link identifiers will be subsequently correlated using the (data) 659 link property correlation function of LMP. The BeginVerify message 660 exchange includes also the capability to associate the interfaces to 661 be discovered to the TE link_id. The latter will be used when the 662 data link properties will be correlated using the LinkSummary 663 message exchange. 665 The importance of discovery in managing links is noticeable among 666 others in the following cases: 667 - during the setup/initial configuration phase: avoid the manual 668 provisioning and configuration of all this information on every 669 node (a N node network with an average connectivity degree D, 670 results in D x N operations) 671 - during modification of the link topology all actions can be 672 performed dynamically without starting to worry about mis- 673 configurations, manual tables, etc. 675 2. Auto-Discovery 677 Auto-discovery can be defined as the combination of an automated 678 (bi-directional) control channel setup and the discovery of the data 679 plane interface_id mappings between neighboring nodes (for their 680 sub-sequent correlation). This mechanism differs from discovery in 681 that it doesn�t consider previous negotiation through the control 682 plane between neighboring nodes before initiating the link 683 verification procedure. Using LMP, auto-discovery relies thus on 684 control channel bootstrapping which is defined as the procedure of 685 automatically discovering the neighboring node (i.e., learning the 686 address of the node) and the IP address(es) of the neighbor�s 687 control channel end-points. 689 In these conditions, the Test message (used during the link 690 connectivity verification procedure) is replaced by a Bootstrap 691 message (see [LMP-BOOT]) that allows the receiving node to setup the 693 D.Papadimitriou et al. Expires May 2003 13 694 (bi-directional) control channel with the sender of the Bootstrap 695 message. This control channel is then used to the send the 696 interface_id mapping to the Bootstrap message sender. 698 3. Flowcharts 700 The following flowcharts summarize the LMP function usage for 701 discovery and auto-discovery: 703 Auto-Discovery Discovery 705 ------------- Existing CC 706 | Bootstrap | In-band Bootstrap LMP Adjacency Up 707 ------------- message . 708 | . 709 | . 710 ------------- ------------------- 711 | CC Setup | LMP Adjacency In-band Test | Link Verification | 712 ------------- setup message ------------------- 713 | | 714 ---------------------- Data Link(s) discovered --------------------- 715 | | 716 ------------- ------------- 717 | Data Link | LinkSummary LinkSummary | Data Link | 718 | Correlation | message message | Correlation | 719 ------------- ------------- 720 | | 721 ------------------------- TE Link discovered ----------------------- 722 | | 723 | | 724 ==================================================================== 725 | | 726 | | 727 ----------------> IGP-TE (OSPF/ISIS) <--------- 729 6.2 Multi-region and TE links 731 A GMPLS-capable node may (under its local control policy 732 configuration) advertise an LSP as a TE link into the same ISIS/OSPF 733 instance as the one that determines the path taken for this LSP. 734 Such a link is referred to as a Forwarding Adjacency (FA) and the 735 corresponding LSP to as a forwarding adjacency LSP or simply FA-LSP 736 (see [MPLS-HIER]). Since the advertised entity appears as a link in 737 OSPF, both end-point nodes of the FA-LSP must belong to the same 738 OSPF area (intra-area improvement of scalability). Afterwards, OSPF 739 floods the link-state information about FAs just as it floods the 740 information about any other TE link allowing other nodes to use FAs 741 as any other TE links for path computation purposes. The use of FA�s 742 provides a mechanism for improving bandwidth utilization when its 743 dynamic allocation can be performed in discrete units; it also 744 enables aggregating forwarding state, and in turn, reducing 745 significantly the number of required labels. Therefore, the usage of 746 FAs can significantly improve the scalability of GMPLS TE-capable 748 D.Papadimitriou et al. Expires May 2003 14 749 control planes, and allow the creation of a (nested) TE LSP 750 hierarchy. Notice that Forwarding Adjacencies can also be unnumbered 751 and thus treated as an unnumbered TE link or an unnumbered component 752 link of a bundled link. 754 In this context, LMP capabilities can be extended to enable FA-LSP 755 initiation, verification and bundling. The usefulness of the 756 proposed mechanism is illustrated by the following multiple LSP 757 regions case description: 759 -- Node(X) <-------------------- LMP -------------------> Node(Y)--- 760 . | | . 761 . | | . 762 . | | . 763 . Node(X) <--LMP--> Node(1)<-..LMP..-->Node(N) <--LMP--> Node(Y) . 764 . . . . 765 . . . . 766 . .<----------LSP Region n+1---------->. . 767 . . 768 .<------------------------- LSP Region n ------------------------->. 770 Typically, Node(1) to Node(N) belongs to one LSP region (for 771 instance, Lambda Switching Capable) and the LSPs established through 772 these nodes crosses the LSP region boundary at Node(X) and Node(Y) 773 that belongs for instance to the TDM region or Lambda Switching 774 Capable (LSC) region (see [draft-ietf-mpls-lsp-hierarchy-07.txt]). 775 When dealing with non-PSC regions, LSPs and TE links are defined as 776 the control plane mapping of the transport plane path and section 777 entities (a.k.a. trails), respectively. Therefore, the LSP 778 established through region (n+1) appears as a TE link at LSP Region 779 (n) and are referred to as a Forwarding Adjacency LSP (FA-LSP). 781 In this context, the main issues are on one hand related to the TE 782 link assignment performed at the boundary between region (n+1) and 783 Region n while only its sub-components may be the object of an FA- 784 LSP setup. Moreover, when an FA is dynamically triggered, the TE 785 attributes of its FA-LSP are inherited from the LSP which induced 786 its creation. Therefore, once setup these FA-LSPs appear at the 787 region n as TE links with the interface switching capability that 788 have raised the corresponding LSPs at region n+1. For instance, the 789 triggering of an FA-LSP with TDM switching capability is only 790 possible if both Node(X) and Node(Y) through the TE links they 791 define with their neighboring nodes (i.e. Node(1) and Node(N)) give 792 access to a lower level region switching capability region such as 793 LSC or FSC. 795 On the other hand, the correlation of FA�s having similar Traffic 796 Engineering (TE) attributes can induce the creation of an FA bundle 797 (here, in this example between Node(X) and Node(Y)). The number of 798 FA�s that may be included in this bundle is at most as large as the 799 number of components of the TE links defined between Node(X) and 801 D.Papadimitriou et al. Expires May 2003 15 802 Node(1) and between Node(N) and Node(Y). In addition, verification 803 of the FA-LSPs is also possible just as data links by simply using 804 the link verification capabilities of LMP. 806 Note also there is a similarity between this and the context where 807 [LMP-WDM] protocol is defined: Node(X) and Node(Y) corresponds to 808 OXC and Node(1) to Node(N) to Optical Line System (OLS); the only 809 exception is that in the latter case, one of the LMP neighbor is a 810 non GMPLS-capable node. 812 7. LMP-WDM Applicability 814 In this section, we address the applicability (and the potential 815 extension) of the LMP(-WDM) capabilities to support information 816 exchange between SONET/SDH nodes connected via a non-SONET/SDH sub- 817 network, for instance a legacy Optical Transport Hierarchy (OTH) 818 sub-network. In this context, the main difference with respect to 819 the LMP-WDM scope is that the switching capable element is not 820 necessarily GMPLS-capable. Therefore, in this case, the server 821 entity may support one or more switching capability and not only 822 optical channel multiplexing capability, as it is the case with 823 Optical Line Systems (see [CCAMP-OLI]). 825 As described in [LMP-WDM], LMP for WDM systems helps in maintenance 826 of control channel connectivity, verification of component link 827 connectivity, and link, fiber, or channel failures within the 828 network between Cross-Connects and Optical Line Systems (OLS). These 829 extensions to LMP are referred to as LMP-WDM and have been designed 830 in compliance with the �carrier requirement� specification (see 831 [OLI]). 833 However, this protocol can be easily extended to cover additional 834 technologies extending beyond �pre-OTN� such as OTH and SONET/SDH. 835 Thus, the three LMP/LMP-WDM scenarios can also be considered for 836 these environments. 838 7.1 Scope and Scenarios 840 Here, using the generic (inter-connection) scenario 2, where the 841 SONET/SDH nodes (LMP Network edge nodes) maintain trails through a 842 non-SONET/SDH network, one gets the following reference 843 architecture: 845 LMP Network <-- --- LMP-WDM Sub-Network --- --> LMP Network 846 | | 847 | | 848 | | 849 SONET/SDH Net <-- --> non-SONET/SDH Sub-Net <-- --> SONET/SDH Net 850 Edge Node(X) Node(1) ---- Node(N) Edge Node(Y) 851 | | | | | | 852 | ---LMP-WDM--- ---LMP-WDM--- | 853 | | 854 <-----------------------LMP-------------------------> 856 D.Papadimitriou et al. Expires May 2003 16 857 The usefulness of the proposed mechanism is illustrated by the 858 following case description: 860 SONET/SDH Node(X) <------------LMP-----------> SONET/SDH Node(Y) 861 ^ ^ 862 | | 863 |LMP-WDM LMP-WDM| 864 | | 865 v v 866 Node(1) <------- Node(2) <-- Subnet --> Node(i) -------> Node(N) 868 \ / 869 -------------------------- OTN -------------------------- 871 Note that in order to achieve consistency one should ensure that 872 Node(1) and Node(N) are necessarily synchronized concerning the 873 information they exchange with both edge Node(X) and Node(Y). 875 Here, the analogy with LMP-WDM (defined between OLS and PXC/OXC) can 876 be drawn as follows: Node(X) and Node(Y) corresponds to PXC/OXC and 877 Node(1) to Node(N) to Optical Line System (OLS); the only exception 878 is that the LMP capable nodes (i.e. Node(X) and Node(Y)) are not 879 necessarily GMPLS-capable nodes. As such, LMP-WDM provides the 880 mechanism enabling cross technology information exchange while LMP 881 provides the peer information exchange. 883 In this model, one assumes that the OTN border nodes are LMP-WDM 884 capable only, while Node(X) and Node(Y) are GMPLS capable (and in 885 particular LMP capable). Using this LMP-WDM, Node(X) can set 886 Performance Monitoring parameters (for instance BER thresholds) to 887 Node(1) (the same occurs at the other side between Node(Y) and 888 Node(N)); the border nodes Node(1) and Node(N) can report alarm 889 (after correlation or not) to the SONET/SDH nodes. 891 One gets also the capability to perform trail tracing between 892 Node(1) and Node(N) without having to modify the hardware 893 capabilities of any of the involved devices. Moreover, the LMP 894 Session between the Node(X) and Node(Y) can be used to provide label 895 association (and subsequently explicit label control if GMPLS is 896 supported by the edge sub-networks). 898 Note that the above Control Channel topology and LMP adjacencies can 899 be modified in order to achieve nested LMP and LMP-WDM sessions: 901 LMP Network <-- --- LMP(-WDM)Sub-Network --- --> LMP Network 902 | | 903 | | 904 SONET/SDH Net <-- --> non-SONET/SDH Sub-Net <-- --> SONET/SDH Net 905 Edge Node(X) Node(1) --- Node(N) Edge Node(Y) 906 | | | | | | 908 D.Papadimitriou et al. Expires May 2003 17 909 | | | | | | 910 --LMP-WDM-- === -- LMP -- === --LMP-WDM-- 912 This case is particularly interesting because SONET/SDH Network edge 913 nodes are only LMP-WDM capable. Using the corresponding sessions 914 would enable to bridge through the LMP session defined between 915 Node(1) and Node(N), information such as the one that would be 916 exchanged using a direct IP Control Channel between edge nodes (i.e. 917 Node(X) and Node(Y)). This would be then equivalent to the 918 architecture described here above where one additional and dedicated 919 LMP session is defined between Node(X) and Node(Y). 921 Here the LMP session between Node(1) and Node(N) (or its hop by hop 922 equivalent) should be fast enough in order to avoid any mismatch of 923 information exchanged when using the LMP-WDM and the LMP session. 925 This scheme also enables a faster correlation of defect indications 926 and notifications (such as the one exchanged through ChannelStatus 927 message). The LMP-WDM session between Node(X) and Node(1) (and 928 between Node(N) and Node(Y)) enables for the former to determine 929 whether or not the failure (a LoS or a LoL for instance, and this 930 depending on the transport plane interface capabilities) is due to 931 an internal sub-network failure or is localized outside this sub- 932 network. 934 7.2 Control Channel 936 Depending on the overhead termination of the edge SONET/SDH nodes 937 either a Section/RS DCC or a Line/MS DCC in-band Control Channel 938 implementation can be considered. 940 7.3 Link (Section) Verification 942 Here, we can apply RS/Section trail tracing capabilities using J0 943 byte of the RS/Section OH for contiguous Link Verification coupled 944 with an out-of-band Test message exchange, as defined in [LMP-SONET- 945 SDH-TEST]. When using RS/Section trail tracing in combination with 946 an out-of-band Test message, the J0 Trace pattern mapping is 947 performed between section termination points (i.e. between OXC1- 948 OLS1, OLS1-OLS2 and OLS2-OXC2). 950 ------ ------ ------ ------ 951 | | ----- | | | | ----- | | 952 | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 | 953 | | ----- | | | | ----- | | 954 ------ ------ ------ ------ 955 ^ ^ ^ ^ ^ ^ 956 | | | | | | 957 | ---LMP-WDM--- ---LMP-WDM--- | 958 | | 959 ----------------------LMP----------------------- 961 D.Papadimitriou et al. Expires May 2003 18 962 In the above figure, the Test procedure used with OLSs is the same 963 as described in [LMP]. The negotiation of the Transport Mechanism 964 (included in the BeginVerify and BeginVerifyAck messages) is used to 965 allow nodes to negotiate a Link Verification method and is essential 966 for OLSs that have access to overhead bytes rather than the payload. 967 The VerifyId (provided by the remote node in the BeginVerifyAck 968 message, and used in all subsequent Test messages) is used to 969 differentiate Test messages from different LMP Link Verification 970 procedures. 972 In addition to the Test procedure described in [LMP], the trace 973 monitoring function of [LMP-SONET-SDH-TEST] may be used for Link 974 Verification when the OLS ports are SONET or SDH capable as it is 975 the case in the present context. 977 In a combined LMP and LMP-WDM context, for example, the OXC1-OLS1 978 LMP session manages the data links between OXC1 and OLS1, and the 979 OXC2-OLS2 LMP session manages the data links between OXC2 and OLS2. 980 However, the OXC1-OXC2 LMP session manages the data links between 981 OXC1 and OXC2, which are actually a concatenation of the data links 982 between OXC1 and OLS1, the DWDM span between OLS1 and OLS2, and the 983 data links between OXC2 and OLS2. Note that it is these concatenated 984 links which comprise the TE links which are advertised in the GMPLS 985 TE link state database. The implication of this is that when the 986 data links between OXC1 and OXC2 are being verified, using the LMP 987 link verification procedure, OLS1 and OLS2 need to make themselves 988 transparent with respect to these concatenated data links. The co- 989 ordination of verification of OXC1-OLS1 and OXC2-OLS2 data links to 990 ensure this transparency is the responsibility of the nodes, OXC1 991 and OXC2. 993 The complete verification procedure is defined as follows: 995 A BeginVerify message is sent from OXC1 to OLS1 with the following 996 Verify Transport Mechanism: transparent upon reception of this 997 message the OLS will send the corresponding data links in a pass- 998 through mode. The same operation is expected to occur at the other 999 end upon reception of the BeginVerify message sent from OXC1 to 1000 OXC2. Thus one sees the following sequence of operations: 1002 BeginVerify OXC1->OLS1 1003 If BeginVerifyNack OLS1->OXC1 1004 then Stop 1005 Otherwise (if BeginVerifyAck OLS1->OXC1) 1006 then continue 1008 BeginVerify OXC1->OXC2 1009 If BeginVerifyNack OXC2->OXC1 1010 then Stop 1011 Otherwise (if BeginVerifyAck OLS1->OXC1) 1012 then continue 1014 BeginVerify OXC2->OLS2 1016 D.Papadimitriou et al. Expires May 2003 19 1017 If BeginVerifyNAck OLS2->OXC2 1018 then BeginVerifyNack OXC2->OXC1 1019 If BeginVerifyAck OLS2->OXC2 1020 then BeginVerifyAck OXC2->OXC1 1022 Once each of entities involved in the procedure have been 1023 synchronized the Link Verification of the data link concatenation 1024 may be performed. 1026 7.4 Link (Section) Property Correlation 1028 TBD 1030 8. Conclusion 1032 By adding the discussed extensions to LMP and LMP-WDM a seamless 1033 bridging of legacy network parts between GMPLS enabled nodes can be 1034 achieved. This will ease the introduction of GMPLS in today�s 1035 networks. This way, legacy parts of the network can be bridged 1036 without impacting procedures and mechanisms in the GMPLS Network. 1038 9. Security Considerations 1040 This document does not introduce additional security considerations 1041 as the one already covered in [LMP]. 1043 10. References 1045 [GMPLS-ARCH] E.Mannie (Editor) et al., �Generalized Multi-Protocol 1046 Label Switching (GMPLS) Architecture�, Internet Draft, 1047 Work in progress, draft-ietf-ccamp-gmpls-architecture- 1048 03.txt. 1050 [GMPLS-LDP] L.Berger (Editor) et al., �Generalized MPLS 1051 Signaling -CR-LDP Extensions�, Internet Draft, Work in 1052 progress, draft-ietf-mpls-generalized-cr-ldp-07.txt. 1054 [GMPLS-RSVP] L.Berger (Editor) et al., �Generalized MPLS Signaling - 1055 RSVP-TE Extensions�, Internet Draft, Work in progress, 1056 draft-ietf-mpls-generalized-rsvp-te-09.txt. 1058 [GMPLS-SIG] L.Berger (Editor) et al., �Generalized MPLS - Signaling 1059 Functional Description�, Internet Draft, Work in 1060 progress, draft-ietf-mpls-generalized-signaling-09.txt. 1062 [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al., 1063 �Generalized MPLS � SDH/Sonet Specifics�, Internet 1064 Draft, Work in progress, draft-ietf-ccamp-gmpls-sonet- 1065 sdh-07.txt, October 2002. 1067 [LMP] J.P.Lang (Editor) et al., �Link Management Protocol,� 1068 Internet Draft, Work in progress, draft-ietf-ccamp- 1069 lmp-06.txt. 1071 D.Papadimitriou et al. Expires May 2003 20 1073 [LMP-SONET-SDH] S.Ansorge et al., �LMP Extensions for Sonet and 1074 SDH�, Internet Draft, Work in progress, draft-ansorge- 1075 ccamp-lmp-sonet-sdh-01.txt. 1077 [LMP-SONET-SDH-TEST] J.Lang, D.Papadimitriou et al. �Sonet/SDH 1078 Encoding for Link Management Protocol (LMP) Test 1079 Messages�, Internet Draft, Work in progress, draft- 1080 ietf-ccamp-lmp-sonet-sdh-00.txt. 1082 [LMP-BOOT] J.Lang, D.Papadimitriou et al. �Control Channel 1083 Bootstrap for Link Management Protocol�, Work in 1084 progress, draft-lang-ccamp-lmp-bootstrap-01.txt. 1086 [LMP-WDM] A.Fredette and J.P.Lang , (Editors), �Link Management 1087 Protocol (LMP) for DWDM Optical Line Systems,� Internet 1088 Draft, Work in progress, draft-ietf-ccamp-lmp-wdm- 1089 01.txt. 1091 [MPLS-BUND] K.Kompella et al., �Link Bundling in MPLS Traffic 1092 Engineering�, Internet Draft, Work in progress, draft- 1093 ietf-mpls-bundle-04.txt. 1095 [MPLS-HIER] K.Kompella et Y.Rekhter, �LSP Hierarchy with 1096 Generalized MPLS TE�, Internet Draft, Work in 1097 progress, draft-ietf-mpls-lsp-hierarchy-08.txt. 1099 [RFC2026] S.Bradner, "The Internet Standards Process -- Revision 1100 3", RFC 2119, October 1996. 1102 [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate 1103 Requirement Levels," RFC 2119. 1105 11. Author's Addresses 1107 Gert Grammel (Alcatel) 1108 Lorenzstrasse 10 1109 70435, Stuttgart, Germany 1110 Phone: +49 711 821-35863 1111 Email: gert.grammel@alcatel.de 1113 Dimitri Papadimitriou (Alcatel) 1114 Francis Wellesplein 1, 1115 B-2018 Antwerpen, Belgium 1116 Phone: +32 3 240-8491 1117 Email: dimitri.papadimitriou@alcatel.be 1119 Stefan Ansorge (Alcatel) 1120 Lorenzstrasse 10 1121 70435, Stuttgart, Germany 1122 Phone: +49 711 821-33744 1123 Email: stefan.ansorge@ks.sel.alcatel.de 1125 D.Papadimitriou et al. Expires May 2003 21 1126 Wojciech Bigos (AGH University of Technology) 1127 Department of Telecommunications 1128 Al. Mickiewicza 30, 1129 30-059 Krakow, Poland 1130 Phone: +48 12 617-3967 1131 Email: bigos@kt.agh.edu.pl 1133 F.-Joachim Westphal (T-Systems Nova) 1134 Technologiezentrum 1135 Goslarer Ufer 35, D-10589 Berlin, Germany 1136 Phone: +49 30 3497-4380 1137 Email: fritz-joachim.westphal@t-systems.com 1139 Frank Tetzlaff (T-Systems Nova) 1140 Technologiezentrum 1141 Goslarer Ufer 35, D-10589 Berlin, Germany 1142 Phone: +49 30 3497-4448 1143 Email: frank.tetzlaff@t-systems.com 1145 Appendix I. SDH Supervision Capabilities 1147 Reference: ITU-T G.806 1149 1. Continuity supervision 1151 Continuity supervision monitors the integrity of the continuity of a 1152 channel. This operation is performed by monitoring the presence/ 1153 absence of the channel information. The monitoring process can check 1154 for the whole information (e.g. LOS at the physical layer) or a 1155 specific mandatory part of it (e.g. multiframe indication for SDH 1156 Tandem Connection Monitoring - TCM). 1158 At path layer networks a replacement signal might be generated by an 1159 open connection matrix (e.g. Unequipped signal for SDH). The 1160 detection of this replacement signal is then an indication of loss 1161 of continuity. 1163 1.1 Loss Of Signal (LoS) 1165 LOS signal supervision is used at the physical layer. Detection of 1166 "incoming signal absent" occurs the incoming power level at the 1167 receiver has dropped to a level corresponding to a high error 1168 condition. 1170 1.2 Unequipped (UNEQ) 1172 The Unequipped defect (UNEQ) shall be detected if n consecutive 1173 frames contain the unequipped activation pattern in the unequipped 1174 overhead. The UNEQ defect shall be cleared if in n consecutive 1175 frames the unequipped deactivation pattern is detected in the 1176 unequipped overhead. Note that Unequipped is only defined for paths 1177 and not for RS/Section or MS/Line trails. 1179 D.Papadimitriou et al. Expires May 2003 22 1180 1.3 TC Loss of Tandem Connection (LTC) 1182 The function shall detect for the presence/absence of the tandem 1183 connection overhead in the TCM overhead by evaluating the multiframe 1184 alignment signal in the TCM multiframe overhead. The loss of tandem 1185 connection defect (LTC) shall be detected if the multiframe 1186 alignment process is in the Out-Of-Multiframe state. The LTC shall 1187 be cleared if the multiframe alignment process is in the In- 1188 Multiframe state. Note that Unequipped defect is only defined for 1189 paths and not for RS/Section or MS/Line trails. 1191 2. Connectivity Supervision 1193 Connectivity supervision monitors the integrity of the routing of 1194 the trail between sink and source. Connectivity is normally only 1195 required if the layer provides flexible connectivity, both 1196 automatically or manually (e.g. static configuration). The 1197 connectivity is supervised by attaching a unique identifier at the 1198 source. If the received identifier does not match this expected 1199 identifier a connectivity defect has occurred. 1201 2.1 Trail Trace Identifier Processing and Trace Identifier Mismatch 1203 TBD. 1205 2.2 Loss of Sequence defect (SQM) 1207 SQM shall be detected if the accepted sequence number does not match 1208 the expected Sequence number. SQM shall be cleared if the accepted 1209 sequence number matches the expected sequence number. 1211 2.3 Loss of Alignment (LOA) 1213 LOA shall be detected if the alignment process cannot perform the 1214 alignment of the individual VC-4s to a common multiframe start (e.g. 1215 LOA is activated if the differential delay exceeds the size of the 1216 alignment buffer). 1218 LOA is the generic defect term referring to loss of frame (LOF), 1219 loss of multiframe (LOM) or loss of pointer (LOP). 1221 Loss Of Frame (LOF) 1223 For STMn/STSn signals, if the out-of-frame state persists for 3 1224 milliseconds, a loss of frame (LOF) state shall be declared. 1225 Once in a LOF state, this state shall be left when the in-frame 1226 state persists continuously for 3 milliseconds. 1228 HOVC Loss Of Multiframe (LOM) 1230 If the multiframe alignment process is in the out-of-multiframe 1231 state and the H4 multiframe overhead byte is not recovered 1232 within N ms (not configurable and in the range 1 ms to 5 ms)), 1234 D.Papadimitriou et al. Expires May 2003 23 1235 a LOM defect shall be declared. Once in a LOM state, this state 1236 shall be exited when the multiframe is recovered. 1238 Loss of Pointer (LOP) 1240 A LOP is declared if the pointer value cannot be interpreted in 1241 the right manner. This might be due to illegal values (out of 1242 range), or due to high frequency of value changes. 1244 3. Signal quality supervision 1246 Signal quality supervision in general monitors the performance of a 1247 trail. If the performance crosses a certain threshold this might 1248 activate a defect. 1250 3.1 Excessive error (EXC) and degraded signal (DEG) 1252 Excessive error and degraded signal defects are to be detected 1253 according to the following process: 1255 - An excessive error (EXC) shall be detected if the equivalent BER 1257 exceeds a preset threshold of 10^(-x), x 1258 = 1260 3 1261 , 1262 4 or 5. The excessive 1263 error defect shall be cleared if the equivalent BER is better than 1264 10^(-x-1). 1266 - A degraded signal (DEG) shall be detected if the equivalent BER 1267 exceeds a preset threshold of 10^(-x), x = 5, 6, 7, 8 or 9. The 1268 degraded signal defect shall be cleared if the equivalent BER is 1269 better than 10^(-x-1). A DEG defect can be detected in �bursty� mode 1270 in case N consecutive seconds the Error Rate is greater than a 1271 provision-able threshold. 1273 SONET uses EXC detector types, while most AU-4 based SDH uses 1274 Alternative DEG detector types. (n consecutive seconds with at least 1275 M block failures per second). 1277 4. Alignment supervision 1279 Alignment supervision checks that frame and frame start can be 1280 correctly recovered. The specific processes depend on the 1281 signal/frame structure and may include: 1282 � frame/multiframe alignment 1283 � pointer processing 1284 � alignment of several independent frames to a common frame start in 1285 case of inverse multiplexing. 1287 If one of these processes fails a related loss of alignment (LOA) 1288 shall be activated. The defect detection process shall be normally 1289 tolerant to single frame slips, but should detect for continuous 1290 frame slips. 1292 5. Maintenance signal supervision 1294 D.Papadimitriou et al. Expires May 2003 24 1295 Maintenance signal supervision is concerned with the detection of 1296 maintenance indications in the signal. 1298 5.1 Alarm Indication Signal (AIS) 1300 If N consecutive frames contain the AIS activation pattern in the 1301 AIS overhead, an AIS failure is detected. The AIS defect shall be 1302 cleared if N consecutive frames contain the AIS deactivation pattern 1303 in the AIS overhead. 1305 For SDH MSn, the MS-AIS is transported over K2 byte while for 1306 VC3/VC4 the AU-AIS is transported over the H1, H2 bytes. 1308 D.Papadimitriou et al. Expires May 2003 25 1309 Full Copyright Statement 1311 "Copyright (C) The Internet Society (date). All Rights Reserved. 1312 This document and translations of it may be copied and furnished to 1313 others, and derivative works that comment on or otherwise explain it 1314 or assist in its implementation may be prepared, copied, published 1315 and distributed, in whole or in part, without restriction of any 1316 kind, provided that the above copyright notice and this paragraph 1317 are included on all such copies and derivative works. However, this 1318 document itself may not be modified in any way, such as by removing 1319 the copyright notice or references to the Internet Society or other 1320 Internet organizations, except as needed for the purpose of 1321 developing Internet standards in which case the procedures for 1322 copyrights defined in the Internet Standards process must be 1323 followed, or as required to translate it into languages other than 1324 English. 1326 The limited permissions granted above are perpetual and will not be 1327 revoked by the Internet Society or its successors or assigns. 1329 This document and the information contained herein is provided on an 1330 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1331 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1332 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1333 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1334 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1336 D.Papadimitriou et al. Expires May 2003 26