idnits 2.17.1 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt: ** The Abstract section seems to be numbered -(138): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(289): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(437): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(574): 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 Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document 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 34 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 18) being 63 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. ** There is 1 instance of too long lines in the document, the longest one being 223 characters in excess of 72. ** The abstract seems to contain references ([2], [LMP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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) -- Missing reference section? '1' on line 21 looks like a reference -- Missing reference section? 'LMP' on line 937 looks like a reference -- Missing reference section? '2' on line 53 looks like a reference -- Missing reference section? 'GMPLS-SONET-SDH-EXT' on line 166 looks like a reference -- Missing reference section? 'GMPLS-SONET-SDH' on line 166 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group S. Ansorge 3 Document: draft-ansorge-ccamp-lmp-sonet-sdh-00.txt D. Papadimitriou 4 Category: Internet draft G. Grammel 5 Expires: May 2002 J. Jones 6 Alcatel 8 J. Lang 9 Calient 11 November 2001 13 LMP Extensions for Sonet and SDH 15 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026 [1]. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. Internet-Drafts are draft documents valid for a maximum of 26 six months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet- Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 For potential updates to the above required-text see: 37 http://www.ietf.org/ietf/1id-guidelines.txt 39 1. Abstract 41 This memo is a companion document to [LMP] detailing Sonet and SDH 42 specifics. This document extends current definition of LMP with 43 respect to standard SDH and SONET features. It provides an overview 44 of different SONET/SDH interface capabilities, standard SONET/SDH 45 features and functions and defines LMP protocol extension to be used 46 with SONET/SDH interfaces. In addition, it considers a relationship 47 description which SONET/SDH features mentioned in this document are 48 supported by LMP and GMPLS signaling respectively. 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 Internet draft � Expires May 2002 1 55 2. Introduction 57 This memo defines the specific Sonet/SDH extension to LMP (see 58 [LMP]) in order to provide the operational and practical needs with 59 respect to some mechanisms currently covered in this protocol such 60 as Link Verification and Link Property Correlation. 62 Thereafter, in the scope of SDH/Sonet link management, this memo 63 proposes enhancing these functions by defining the required LMP 64 extension to provide: 65 - Enhanced Link Verification using the J0 Test Message 66 - Enhanced Operational Link Status request and Fault Localization 67 by enabling SDH/Sonet Supervision capabilities in the 68 ChannelStatus message 69 - Enhanced Link Property Correlation (Link Summarization) 70 procedure by enabling the exchange of the link protection 71 capabilities including Linear and Ring protection 73 For this purpose this memo first review the Sonet/SDH equipment 74 capabilities to be considered by the LMP extensions (Section 3) in 75 order to improve the Link Verification procedure using different 76 kind of Sonet/SDH equipment. Section 4 summarizes the Sonet/SDH 77 supervision capabilities in order to extend the ChannelStatus field 78 included in the ChannelStatus message. The next sections (Section 5 79 to 7) detail the mapping between the Sonet/SDH capabilities and the 80 LMP protocol extensions. 82 3. SONET/SDH Equipment capabilities 84 This section briefly summarizes the SONET/SDH equipment capabilities 85 to be considered for LMP extension purposes. 87 3.1 SONET/SDH layer functions 89 The SONET/SDH signal frame is decomposed in Section/Regenerator 90 Section (RS) and Line/Multiplex Section (MS) and payload. The 91 payload may carry multiple paths whereby each path might be subject 92 to pointer processing. The Section/RS, Line/MS and Path are treated 93 as separate layers. 95 Several functions are defined, in particular: 96 - Trail Termination (TT) function: applicable whenever the layer is 97 terminated and generated. Section/RS TT terminates and generates 98 the Section/RS trail, Line/MS_TT terminates and generates the 99 Line/MS trail. This function is contiguously sending out a signal. 100 - Adaptation function: applicable between layers to map client layer 101 signals into layer frame structure. If no client signal is 102 applicable a defined signal shall be used. The adaptation function 103 can coexist only with a TT function. 104 - Supervisory Trail Termination (STT) function: applicable when the 105 layer is not carrying user traffic. In this case the function 106 generates a valid signal that can be supervised from the other 107 side. 109 Internet Draft � Expires May 2002 2 110 - Path Overhead Monitoring (POM) function: applicable when the layer 111 is carrying user traffic. This function is used to monitor user 112 traffic and might be used to determine the path state. 114 3.2 Trail Trace Identifier in SONET/SDH 116 Basically SONET/SDH link verification is provided in-band using 117 Trail Trace Identifiers (TTI). At the Section/RS layer this function 118 is implemented by using the J0 byte, on higher order paths by using 119 the J1 byte and on lower order paths by using the J2 byte. When a 120 trace mismatch occurs an identifier (Trace Identifier Mismatch - 121 TIM) is generated: an alarm raised on disagreement on expected and 122 received TTI. See Appendix 1 for more details on TTI using J0. 124 3.3 Other SONET/SDH capabilities 126 3.3.1 Line/MS capabilities 128 Line/MS Terminating Equipment (LTE) equipment terminates and 129 generates the Section/RS and Line/MS overhead. Other equipment could 130 be one of the following with respect to the TTI function: 131 - Section Generating Equipment (SGE): As long as the link is not 132 allocated the SGE shall transmit a defined signal (like 133 supervisory unequipped signal) which includes at least J0. 134 Once the link is allocated the SGE function is disabled and the 135 section monitoring function might be enabled (non intrusive). 136 - AIS generating Equipment (AGE): As long as the link is not 137 allocated the AGE shall emit a defined AIS signal with valid 138 SDH/SONET frame and all �1� in the payload. This is a special form 139 of SGE without support of valid J0 generation. 140 - Section Monitoring Equipment (SME): As long as the link is 141 allocated the end to end path is monitored in both directions on 142 received and transmitted J0. The bi-directional function is only 143 mandatory on network border nodes. The unidirectional function is 144 optional at receiver side of intermediate nodes to determine the 145 path state 146 - SDH/SONET Extension LMP-capable nodes: such equipment is treated 147 like STE as either J0 or DCC bytes shall be accessible for Link 148 Verification purposes. 150 3.3.2 Multiplexing capabilities 152 Three types of multiplexing capabilities can be considered: 153 - Fixed multiplexer: In this case the adaptation function 154 (multiplexing) is not modifiable 155 - Flexible multiplexer: In this case the multiplexing scheme can be 156 adapted to the payload need, e.g. an AUG4 can be used for an AU4- 157 4c or 4 times AU4. This is done using the standard multiplexing 158 scheme (multiple of 4) 159 - Transparent multiplexer: In this case the multiplexing function 160 does not take care on the position and payload itself. Any 161 multiple of element types at any position is supported. 163 Internet Draft � Expires May 2002 3 164 3.3.3 Concatenation capabilities 166 Considerations about Contiguous Concatenation are covered in [GMPLS- 167 SONET-SDH] and [GMPLS-SONET-SDH-EXT]. 169 3.3.4 Monitoring capabilities 171 Three monitoring types are defined for SDH/Sonet equipment: 172 - Supervisory: Monitors an unallocated link or path state based on 173 the active Supervisory TT at the other end 174 - Non intrusive: Monitors an allocated link or path state based on 175 end to end TT information 176 - Inherent: Monitors whether the signal can be determined and is 177 mainly based on the adaptation function 179 3.3.5 Loopback capabilities 181 In addition SDH/SONET ports provide loopback functions. Two loopback 182 types are defined: 183 - Line/MS loopback: provides a loopback capability closest to the 184 physical line. The received signal is directly looped back to the 185 sender via the transmit port. The transmitted signal from the 186 system is preempted by the loopback signal. This feature might 187 be used for link verification. 188 - Terminal loopback: provides a loopback capability closest to the 189 physical line back to the system. The transmit signal is directly 190 looped back to the system via the receive port. The line receiving 191 signal is preempted by the loopback signal. This feature might be 192 used to test a connection. 194 3.3.6 Protection capabilities 196 See ITU-T G.841 for protection capabilities. 198 4. Sonet/SDH Supervision Capabilities 200 Sonet/SDH Supervision covers Continuity, Connectivity, Signal 201 Quality and Alignment Supervision. These are briefly summarized in 202 the next paragraphs of this section. 204 4.1 Continuity supervision 206 Continuity supervision refers to the integrity of the continuity of 207 a channel. This is performed by monitoring the presence/absence of 208 the channel information. The monitoring process can check for the 209 whole information (e.g. LOS at the physical layer) or a specific 210 mandatory part of it (e.g. multiframe indication for SDH Tandem 211 Connection Monitoring - TCM). 213 At the path layer a replacement signal might be generated by an open 214 connection matrix (e.g. Unequipped signal for SDH). The detection of 215 this replacement signal indicates the loss of continuity. 217 Internet Draft � Expires May 2002 4 218 4.1.2 Loss Of Signal (LOS) 220 LOS signal supervision is used at the physical layer. Detection of 221 "incoming signal absent" occurs when the incoming power level at the 222 receiver has dropped to a level corresponding to a high error 223 condition. 225 4.1.3 Unequipped (UNEQ) 227 The Unequipped defect (UNEQ) shall be detected if N consecutive 228 frames contain the unequipped activation pattern in the unequipped 229 overhead. The UNEQ defect shall be cleared if in N consecutive 230 frames the unequipped deactivation pattern is detected in the 231 unequipped overhead. Note that strictly speaking Unequipped defect 232 is only defined for paths and not for Section/RS or Line/MS trails. 234 4.1.4 TC Loss of Tandem Connection (LTC) 236 The function shall detect for the presence/absence of the tandem 237 connection overhead in the TCM overhead by evaluating the multiframe 238 alignment signal in the TCM multiframe overhead. The loss of tandem 239 connection defect (LTC) shall be detected if the multiframe 240 alignment process is in the Out Of Multiframe (OOM) state. The LTC 241 shall be cleared if the multiframe alignment process is in the In 242 Multiframe (IM) state. 244 4.2 Connectivity Supervision 246 Connectivity supervision monitors the integrity of the routing of 247 the trail between sink and source. Connectivity is normally only 248 required if the layer provides flexible connectivity, both 249 automatically or manually (e.g. static configuration). The 250 connectivity is supervised by attaching a unique identifier at the 251 source. If the received identifier does not match this expected 252 identifier a connectivity defect has occurred. 254 4.2.1 Trace Identifier Mismatch (TTI) and Processing 256 See Section 3.3. 258 4.2.2 Loss of Sequence defect (SQM) 260 SQM shall be detected if the accepted sequence number does not match 261 the expected Sequence number. SQM shall be cleared if the accepted 262 sequence number matches the expected sequence number. 264 4.2.3 Loss of Alignment (LOA) 266 LOA shall be detected if the alignment process cannot perform the 267 alignment of the individual VC-4s to a common multiframe start (e.g. 268 LOA is activated if the differential delay exceeds the size of the 269 alignment buffer). Notice that LOA is the generic defect term 271 Internet Draft � Expires May 2002 5 272 referring to loss of frame (LOF), Loss Of Multiframe (LOM) or Loss 273 Of Pointer (LOP). We refer to Appendix 2 for more details on LOA. 275 4.3 Signal Quality supervision 277 Signal quality supervision enables monitoring the performance of a 278 trail. If the performance falls below a certain threshold this might 279 activate a defect. Details one excessive errors (EXC) and degraded 280 signal (DEG) are covered in Appendix 3. 282 4.4 Alignment Supervision 284 Alignment supervision checks that the frame and frame start can be 285 correctly recovered. The specific processes depend on the 286 signal/frame structure and may include: 287 � frame/multiframe alignment 288 � pointer processing 289 � alignment of several independent frames to a common frame start in 290 case of inverse multiplexing 292 If one of these processes fails a related Loss Of Alignment (LOA) 293 shall be activated. 295 4.5 Maintenance Supervision 297 Maintenance signal supervision is concerned with the detection of 298 maintenance indications in the signal. 300 4.5.1 Alarm Indication Signal (AIS) 302 If N consecutive frames contain the AIS activation pattern in the 303 AIS overhead, an AIS failure is detected. The AIS defect shall be 304 cleared if N consecutive frames contain the AIS deactivation pattern 305 in the AIS overhead. 307 For SDH MSn, the MS-AIS is transported over K2 byte while for 308 VC3/VC4 the AU-AIS is transported over the H1, H2 bytes. 310 5. Mapping SDH/SONET capabilities to LMP functions 312 5.1 Link Verification 314 5.1.1 Contiguous Link Verification 316 Usually, the link capabilities and activation shall be provided in 317 the DATA LINK objects of the Link Summary message (e.g. LTE, STE, 318 SGE, AGE, POM, etc). For instance, when considering STE or LTE 319 equipment, J0 is always inserted and monitored on both sides of the 320 link. 322 The following procedures can be defined when using J0 test message: 323 - LTE equipment: As J0 is contiguously transmitted on the link, the 324 Link Summary message shall contain the received and transmitted J0 326 Internet Draft � Expires May 2002 6 327 on the port. In case of agreement (capability negotiation both 328 sides are LTE) the standard TTI (Trail Termination Identifier) 329 functions are activated (monitor received J0) and raise a TIM 330 alarm in case of disagreement. 331 - SGE equipment: As J0 is contiguously transmitted on the link as 332 long as the link is not allocated Link Summary message shall 333 contain the received and transmitted SGE J0. The activated SGE 334 function shall be indicated in the link summary message. 335 - POM (Path Overhead Monitoring) equipment: As J0 is contiguously 336 monitored on both sides of the link as long as the link is 337 allocated the channel status message shall contain the received 338 and transmitted J0 for verification. 340 5.1.2 Out-of-band J0 Test Message 342 Capable of communicating using standard J0 byte as defined in ITU-T 343 G.707 for section trace monitoring. In this case, the Test message 344 is not transmitted using the J0 byte (i.e. over the Data Link) but 345 sent over the Control Channel and correlated for consistency check 346 to the received J0 pattern. In that case the Interface ID determines 347 the interface over which the standard J0 byte are transmitted in- 348 band. This feature is thus provided to accommodate Link Verification 349 when using legacy Sonet/SDH LTE equipment. 351 In order to get the mapping between the Interface ID over which the 352 J0 Test message is sent and the J0 pattern sent in-band, one must 353 provide the correlation between this pattern and the J0 Test 354 message. 356 5.2 Link Verification 358 5.2.1 LTE and STE transparent equipment (Contiguous) 360 The entire link verification procedure for LTE and STE is based on 361 standard SDH/SONET Trail Trace Identifier (TTI) functions in all 362 cases here contiguously generated and terminated on both link sides. 363 The entire link verification (BeginVerify, Test, VerifyEnd, and 364 corresponding acknowledgements) procedure as described in [LMP] is 365 replaced by exchanging transmitted and received TTI within the DATA 366 LINK object in the LinkSummary message. 368 In case of agreement as a result of Link Summary message exchange 369 the received/negotiated TTI is used as expected TTI and TIM alarm is 370 activated. 372 5.2.2 Fully transparent equipment (Supervisory) 374 Link verification for fully transparent equipment must distinguish 375 between equipment capable to provide Supervisory Trail Termination 376 function and/or path monitoring function. 378 For equipment providing Supervisory Trail Termination function the 379 same rules applies as described above (see Section 5.2.1) as long 381 Internet Draft � Expires May 2002 7 382 the path is not allocated for user traffic. As soon the path is 383 allocated for user traffic the Supervisory Trail Termination 384 function is deactivated and user traffic can pass. Optionally the 385 user traffic can be monitored for path state validation. 387 For equipment not capable to provide Supervisory Trail Termination 388 function the J0 based link verification procedure cannot be applied. 389 Those links can only be tested with loopback capabilities (see 390 Section 5.3). 392 5.2.3 LTE terminating equipment (Out-of-band) 394 An LTE exchanging within its overhead a Sonet/SDH Section/RS Trace 395 over the J0 byte (while Path tracing uses J1 or J2 byte). If the 396 trace exchanged over the out-of-band Test message does not match the 397 in-band Section/RS Trace message, the node report the mismatch 398 condition (TIM). 400 1. Test Message (MsgType = 10) 402 The Test message is transmitted over the control channel; the 403 matching with the Section/RS trace message is used to verify its 404 physical connectivity. This message is transmitted as an IP packet 405 with payload format as follows: 407 ::= 408 409 411 The above transmission order MUST be followed. 413 Note that this Test Message is sent over a control channel and NOT 414 over a data link and is used to request a node to extract from one 415 or more data links for a specific trace value at a given interface 416 ID. 418 The local (transmitting) node sends a given Test message 419 periodically (at least once every VerifyInterval ms) on the 420 corresponding data link until 421 (1) it receives a correlating TestStatusSuccess or TestStatusFailure 422 message on the control channel from the remote (receiving) node 423 (2) or all active control channels between the two nodes have 424 failed. 426 The remote node will send a given TestStatus message periodically 427 over the control channel until it receives either a correlating 428 TestStatusAck message or an EndVerify message is received over the 429 control channel. 431 2. TestStatusSuccess Message (MsgType = 11) 433 The TestStatusSuccess message is transmitted over the control 434 channel and is used to transmit the mapping between the local 436 Internet Draft � Expires May 2002 8 437 Interface Id � In-band Section/RS Trace and the Interface Id � Out- 438 of-band Section/RS Trace that was received in the Test message. 440 ::= 441 442 444 The above transmission order MUST be followed. 446 The contents of the REMOTE_INTERFACE_ID object MUST be obtained from 447 the corresponding Test message being positively acknowledged. The 448 Trace Message (received through the control channel and expected 449 from the data link aren�t exchanged in case of test success) 451 3. TestStatusFailure Message (MsgType = 12) 453 The TestStatusFailure message is transmitted over the control 454 channel and is used to indicate that the Section/RS trace message 455 (exchanged over data links) was not received. 457 ::= 459 The above transmission order MUST be followed. 461 4. TestStatusAck Message (MsgType = 13) 463 The TestStatusAck message is used to acknowledge receipt of the 464 TestStatusSuccess or TestStatusFailure messages. 466 ::= 467 469 The above transmission order MUST be followed. 471 The contents of the MESSAGE_ID_ACK object MUST be obtained from the 472 TestStatusSuccess or TestStatusFailure message being acknowledged. 474 5. TestMismatch Message (MsgType = 21) 476 The TestStatusFailure message is transmitted over the control 477 channel and is used to indicate a Section/RS Trace Mismatch between 478 the in-band and the out-of-band Section/RS Trace. 480 ::= 481 482 484 The above transmission order MUST be followed. 486 6. TestMismatchAck Message (MsgType = 22) 488 The TestMismatchAck message is used to acknowledge receipt of a 489 TestMismatch message. 491 Internet Draft � Expires May 2002 9 492 ::= 493 495 The above transmission order MUST be followed. 497 Additional Object Class: TRACE MESSAGE Class (Class = 22) See 498 Section 7.1. 500 For bi-directional links two Trace Messages are exchanged one for 501 receive direction and one for the transmit direction (TRANSMIT TRACE 502 and RECEIVE TRACE MESSAGE, respectively). 504 5.3 Loopback function 506 5.3.1 Description 508 With AGE equipment, no overhead can be monitored or generated on a 509 Line/MS, the node must therefore provide Line/MS loopback function. 510 A sender is requesting a Line/MS loopback for a certain time to test 511 the Line/MS and reading its own generated data. 513 This request is used to indicate the direction of the loopback; 514 either towards the Line/MS or towards the system and therefore not 515 used for layers. 517 If the sender is of SGE type, it can verify its transmitted signal 518 with respect to the signal on the receive port. If both signals 519 match, the corresponding ports are wired in the right manner. 521 To avoid ambiguous interpretation of loopback signals a node shall 522 support only one loopback function at a time. Consequently, on time- 523 by-time basis, these capabilities are mutually exclusive. Moreover, 524 the loopback trigger must hence always direct to a single port. 526 5.3.2 Loopback Trigger 528 When Loopback Trigger function is used, the sender does not wait for 529 a test message to be received from remote side since the receiving 530 port internally generates the test message. 532 To support AGE-AGE links a test generator shall be applicable at 533 each node to test links. The test generator equipment must be cross- 534 connected to the desired port for testing. 536 Loopback functions can be requested on single interface base by the 537 LMP neighbor. This operation is based on LinkVerify message exchange 538 without using the Test, TestStatusSuccess, TestStatusFailed, and 539 TestStatusAck messages. BeginVerify objects must be extended to 540 invoke loopback activation on neighbor side. The VerifyEnd objects 541 must be extended to release the loopback function. 543 Internet Draft � Expires May 2002 10 544 While the loopback is active the initiator MUST verify its receiving 545 signal side whether it matches with the emitting side. Basis for 546 this validation can be standard Sonet/SDH LTE and STE function 547 validating the received TTI. 549 5.4 Contiguous Path monitoring 551 Even when interface (or path) is allocated for user traffic, 552 Sonet/SDH provides means to monitor the path by using a path 553 monitoring function. 555 Activation of path monitoring function is usually beside the 556 responsibility of signaling based on specific service 557 characteristics. It can be activated by the ChannelStatus messages. 558 Nevertheless once the path monitoring function is activated it can 559 be used for LinkVerify and ChannelStatus purposes by exchanging the 560 ingress and egress monitored TTI. ChannelStatus messages will 561 activate/deactivate SGE or AGE functions. 563 6. Link Property Correlation 565 6.1 Multiplexing Capabilities 567 Multiplexer alignment (except for transparent multiplexers) implies 568 that the payload structure of both ports must be aligned to avoid 569 pointer processing alarms. Therefore the multiplexing scheme and 570 capabilities shall be included in the DATA LINK object (Class = 17) 571 of the Link Summary message. In particular: 572 - Fixed multiplexer : Capability Min = Max 573 - Flexible multiplexer : Capability Min < Max 574 - Transparent multiplexer: Capability Min = �infinite value� = Max 576 6.2 Protection 578 Link protection including Linear and Ring protection capabilities 579 can be exchanged between LMP neighbors by using LinkSummary message. 581 Linear protection can be take one (or more than one) of the 582 following configuration: 583 - Linear 1+1 dedicated protection 584 - Linear 1:1 dedicated protection 585 - Linear 1:N shared protection 587 Ring protection can be configured using the following capabilities 588 when available: 589 - Line/MS-DPRing : Dedicated MS/Line protection ring 590 - Line/MS-SPRing : 2-fiber MS/Line Shared protection ring 591 - Line/MS-SPRing : 4-fiber MS/Line Shared protection ring 592 - Path-DPRing : Dedicated Path protection ring 593 - Path-SPRing : Shared Path protection ring 595 7. LMP protocol extensions 597 Internet Draft � Expires May 2002 11 598 7.1 Link Verification 600 To support contiguous Link Verification the following new object 601 types are defined (here TRACE refers to TTI): 603 TRACE MESSAGE Class (Class = 22) 605 - TRANSMIT TRACE (C-Type = 1) 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Trace Type | Trace Flags | Trace Length | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | | 613 // Trace Message (16 bytes) // 614 | | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 This object is non-negotiable (N = 0). 619 Trace Message Type: 8 bits 621 Defines the type of the test message includes: 622 1 � Sonet Section and SDH RS Trace (J0 Byte) 623 2 � Sonet STS-SPE and SDH HO Path Trace (J1 Byte) 624 3 � Sonet VT and SDH LO Path Trace (J2 Byte) 626 There are no other types for SDH/Sonet 628 Trace Flags: 8 bits 630 Describe the scope of the TTI to which it applies 632 0x00 Unknown 633 0x01 Trail Termination (TT) 634 0x02 Supervisory Trail Termination (STT) 635 0x04 Path Overhead Monitor (POM) 637 Trace Length: 16 bits 639 The Length in bytes of the trace message provided. 641 Trace Message: 643 Transmitted Trace message. The valid length and 644 value combinations are determined by the specific technology 645 (e.g., Sonet or SDH). The message MUST be padded with zeros 646 to a 32-bit boundary, if necessary. 648 - RECEIVE_TRACE (C-Type = 2) 650 0 1 2 3 652 Internet Draft � Expires May 2002 12 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Trace Type | Trace Flags | Trace Length | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | | 658 // Trace Message (16 bytes) // 659 | | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 The LinkSummary Message (MsgType = 14) used to synchronize the 663 Interface Ids and correlate the properties of the TE link. The 664 format of the LinkSummary message is as follows: 666 ::= 667 668 [] [] 669 [...] 671 Moreover, the DATA LINK Object (Class = 17, C-Type = 1 and 2) Flags 672 field must include the following additional values: 674 0x01 Interface Type (see [LMP]) 675 0x02 Allocated Link (see [LMP]) 676 0x04 Contiguous Link Verification 677 0x08 Supervisory Link Verification 678 0x10 Path Monitoring 680 To enable the transport of the Test Message over the control 681 channel, the BEGIN_VERIFY object (Class = 13, C-Type = 1), the 682 Verify Transport Mechanism field (16 bits) must include an 683 additional value. More precisely, 685 Verify Transport Mechanism: 16 bits 687 This defines the transport mechanism for the Test Messages. 688 The scope of this bit mask is restricted to each link 689 encoding type. The local node will set the bits 690 corresponding to the various mechanisms it can support for 691 transmitting Test messages. The receiver chooses the 692 appropriate mechanism in the BeginVerifyAck message. 694 For Sonet/SDH Encoding Type, the following flags are 695 defined: 697 0x01 J0-16 698 0x02 DCCS 699 0x04 DCCL 700 0x08 J0-16 (TestMessage over Control Channel) 702 7.2 Loopback Verification 704 Internet Draft � Expires May 2002 13 705 The Flag field (16 bits) defined in the BEGIN_VERIFY_object (Class = 706 13, C-Type = 1) shall be extended to cover link loopback function: 708 Flags: 16 bits 710 The following flags are defined: 712 0x01 Verify all Links 714 If this bit is set, the verification process checks all 715 unallocated links; else it only verifies new ports or 716 component links that are to be added to this TE link. 718 0x02 Data Link Type 720 If set, the data links to be verified are ports, 721 otherwise they are component links 723 0x04 Loopback 725 If set, the data link loopback function is activated. 727 The loopback function is deactivated in case of following events: 728 a) at the end of the verify interval (VerifyDeadInterval) 729 b) on receipt of EndVerify message 730 c) when the port is allocated for user traffic 732 Moreover VerifyDeadInterval and Verify_Transport_Mechanism fields in 733 the BEGIN_VERIFY_ACK (Class = 14, C-Type = 1) fields must be 734 configured accordingly 736 7.3 Supervision 738 The ChannelStatus message is sent over the control channel and is 739 used to notify an LMP neighbor of the status of a data link. 741 The ChannelStatus (31-bit) field defined as the CHANNEL_STATUS 742 Object (Class = 18, C-Type = 1) of the ChannelStatus Message 743 includes the following additional values in order to include 744 Sonet/SDH supervision capabilities: 746 For Continuity Supervision purposes (see Section 4): 748 Value Status Condition 749 ----- ---------------- 750 5 Loss Of Signal (LOS) 751 6 Unequipped (UNEQ) 752 7 Unequipped Available (UNEQa) 753 8 Unequipped Unavailable (UNEQu) 754 9 Automatic Report Control (ARC) 755 10 Loss Of Tandem Connection (LTC) 757 For Connectivity Supervision purposes (see Section 4): 759 Internet Draft � Expires May 2002 14 760 Value Status Condition 761 ----- ---------------- 762 16 Trace Identifier Mismatch (TIM) 763 17 Loss of Sequence (SQM) 764 18 Loss of Alignment (LOA) 765 19 Loss of Frame (LOF) 766 20 HOVC Loss Of Multiframe (LOM) 767 21 Loss of Pointer (LOP) 769 For Maintenance Supervision purposes (see Section 4): 771 Value Status Condition 772 ----- ---------------- 773 22 MS/Line AIS (AIS) 775 7.4 Link Protection 777 As mentioned in Section 3.3, for protection purposes the standard 778 MSP/APS protocol (as defined in G.841) is used. In order to exchange 779 protection parameter during the Link Property Correlation procedure, 780 links must be identified by (component) Interface Ids and protection 781 group by Protection Group Ids. 783 This Protection Group Id includes the references to the links, 784 whether a link is to be considered primary or secondary (refer to as 785 the Protection Status (PS) and a Link Priority for 1:N protections 786 purposes. 788 The following object is exchange in the LinkSummary message. After 789 exchanging this message, the procedure described in Section 4 of 790 [LMP] applies. 792 7.4.1 LINEAR PROTECTION Class 794 LINEAR PROTECTION Class (Class = 23) 796 - C-Type = 1 798 0 1 2 3 799 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 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Protection Group ID | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Linear Prot. | Reserved | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Interface ID | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | PS | Priority | Reserved | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | | 810 // ... // 811 | | 813 Internet Draft � Expires May 2002 15 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Interface ID | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | PS | Priority | Reserved | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 Protection Group ID: 32 bits 822 Identifies the Protection Group 824 Linear Protection Type: 8 bits 826 0x00 Unknown 827 0x01 Linear 1+1 dedicated protection 828 0x02 Linear 1:1 dedicated protection 829 0x04 Linear 1:N shared protection 831 Priority: 8 bits 833 Defines the priority levels of the link included in 1:N 834 shared protection groups. Default value is 0. 836 Protection Status (PS): 8 bits 838 0x00 Unknown 839 0x01 Primary (Working) 840 0x02 Secondary (Protecting) 842 Reserved fields: must be zeroed when sent and ignored when 843 received 845 7.4.2 RING PROTECTION Class 847 RING PROTECTION Class (Class = 24) 849 - East Node: C-Type = 1 851 0 1 2 3 852 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 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Protection Group ID | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 |Ring Protection| Reserved | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | East Node ID | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Interface ID | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | PS | Priority | Reserved | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | | 865 // ... // 866 | | 868 Internet Draft � Expires May 2002 16 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Interface ID | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | PS | Priority | Reserved | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 - West Node: C-Type = 2 877 0 1 2 3 878 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 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Protection Group ID | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 |Ring Protection| Reserved | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | East Node ID | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Interface ID | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | PS | Priority | Reserved | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | | 891 // ... // 892 | | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Interface ID | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | PS | Priority | Reserved | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 Protection Group ID: 32 bits 901 Identifies the Protection Group 903 Interface ID: 32 bits (see [LMP]) 905 Ring Protection Type: 8 bits 907 0x00 Unknown 908 0x01 Line/MS-DPRing 909 0x02 Line/MS-SPRing (2-fiber) 910 0x04 Line/MS-SPRing (4-fiber) 911 0x08 Path-DPRing 912 0x10 Path-SPRing 914 Priority: 8 bits 916 Defines the priority levels of the link included in 1:N 917 shared protection groups. Default value is 0. 919 Protection Status (PS): 8 bits 921 0x00 Unknown 923 Internet Draft � Expires May 2002 17 924 0x01 Primary (Working) 925 0x02 Secondary (Protecting) 927 Reserved fields: must be zeroed when sent and ignored when 928 received 930 7.5 Multiplexing Capabilities 932 To be covered in a future release. 934 8. Security Considerations 936 This document does not imply additional security considerations to 937 the one already defined in [LMP]. 939 9. References 941 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 942 9, RFC 2026, October 1996. 944 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 945 Levels", BCP 14, RFC 2119, March 1997 947 3 Lang, J. et al, �Link Management Protocol v1�, Internet Draft, 948 draft-ietf-ccamp-lmp-02.txt, October 2001 950 10. Acknowledgments 952 The authors would like to thank Bernard Sales, Emmanuel Desmet, for 953 their constructive comments and inputs. 955 11. Author's Addresses 956 Stefan Ansorge 957 Alcatel SEL AG 958 E-mail: Stefan.ansorge@alcatel.de 960 Gert Grammel 961 Alcatel 962 Via Trento 30, 963 I-20059 Vimercate, Italy 964 Phone: +39 039 686-7060 965 Email: gert.grammel@netit.alcatel.it 967 Jim Jones 968 Alcatel 969 3400 W. Plano Parkway, 970 Plano, TX 75075, USA 971 Phone: +1 972 519-2744 972 Email: Jim.D.Jones1@usa.alcatel.com 974 Dimitri Papadimitriou 975 Alcatel 976 Francis Wellesplein 1, 977 B-2018 Antwerpen, Belgium 978 Phone: +32 3 240-8491 979 Email: Dimitri.Papadimitriou@alcatel.be 981 Internet Draft � Expires May 2002 18 982 Jonathan P. Lang 983 Calient Networks 984 25 Castilian Drive 985 Goleta, CA 93117, USA 986 Email: jplang@calient.net 988 12. Appendix 1: Trail Trace Identifier (TTI) 990 A Trail Trace Identifier (TTI) is defined as a 16-byte frame 991 structure. The first byte is a header byte, which includes the 992 result of a CRC-7 calculation over the previous frame. The following 993 15 bytes are used for the transport of 15 T.50 characters required 994 for the Section Access Point Identifier (SAPI). The ones used for 995 the Test Message. Moreover the bit 1 of each byte (of the 16 byte 996 frame structure) is the trace identifier frame alignment signal 997 (value = 1000 0000 0000 0000). 999 The structure for the J0 16 byte frame: 1001 0 1 2 3 4 5 6 7 1002 1 1 x x x x x x x <= CRC-7 1003 2 0 - - - - - - - 1004 3 0 - - - - - - - 1005 4 0 - - - - - - - 1006 . . - - - - - - - 1007 16 0 - - - - - - - 1009 A TTI is generated by the trail termination functions and 1010 supervisory trail termination functions. As mentioned before the 1011 trail termination function is contiguously sending out a valid 1012 signal and a stable Trail trace identifier. The supervisory trail 1013 termination function is sending out a valid signal with a stable 1014 trail trace identifier as long the line or path is not allocated for 1015 user services. 1017 Derived Management functions on TTI for the control plane are: 1018 - Send TTI: provision the emitted TTI 1019 - Received TTI: retrieve the received TTI 1020 - Expected TTI: check the received TTI with an expected TTI 1021 - Trace Identifier Mismatch (TIM): an alarm raised on disagreement 1022 on expected and received TTI 1024 Appendix 2 � Loss Of Alignment (LOA) 1026 LOA is the generic defect term referring to Loss Of Frame (LOF), 1027 Loss Of Multiframe (LOM) or Loss Of Pointer (LOP). The following 1028 paragraphs describes each of these defects: 1030 Loss Of Frame (LOF) 1032 For STMn/STSn signals, if the out-of-frame state persists for 3 1033 milliseconds, a loss of frame (LOF) state shall be declared. 1035 Internet Draft � Expires May 2002 19 1036 Once in a LOF state, this state shall be left when the in-frame 1037 state persists continuously for 3 milliseconds. 1039 HOVC Loss Of Multiframe (LOM) 1041 If the multiframe alignment process is in the out-of-multiframe 1042 state and the H4 multiframe overhead byte is not recovered 1043 within N ms (not configurable and in the range 1 ms to 5 ms)), 1044 a LOM defect shall be declared. Once in a LOM state, this state 1045 shall be exited when the multiframe is recovered. 1047 Loss of Pointer (LOP) 1049 A LOP is declared if the pointer value cannot be interpreted in 1050 the right manner. This might be due to illegal values (out of 1051 range), or due to high frequency of value changes. 1053 Appendix 3 - Excessive error (EXC) and Degraded signal (DEG) 1055 Excessive error and degraded signal defects are to be detected 1056 according to the following process: 1058 - An excessive error (EXC) shall be detected if the equivalent BER 1060 exceeds a preset threshold of 10^(-x), x = 3 , 4 or 5. The excessive 1061 error defect shall be cleared if the equivalent BER is better than 1062 10^(-x-1). 1064 - A degraded signal (DEG) shall be detected if the equivalent BER 1065 exceeds a preset threshold of 10^(-x), x = 5, 6, 7, 8 or 9. The 1066 degraded signal defect shall be cleared if the equivalent BER is 1067 better than 10^(-x-1). A DEG defect can be detected in �bursty� mode 1068 in case N consecutive seconds the Error Rate is greater than a 1069 provision-able threshold. 1071 SONET uses EXC detector types, while most AU-4 based SDH uses 1072 Alternative DEG detector types. 1074 Internet Draft � Expires May 2002 20 1075 Full Copyright Statement 1077 "Copyright (C) The Internet Society (date). All Rights Reserved. 1078 This document and translations of it may be copied and furnished to 1079 others, and derivative works that comment on or otherwise explain it 1080 or assist in its implementation may be prepared, copied, published 1081 and distributed, in whole or in part, without restriction of any 1082 kind, provided that the above copyright notice and this paragraph 1083 are included on all such copies and derivative works. However, this 1084 document itself may not be modified in any way, such as by removing 1085 the copyright notice or references to the Internet Society or other 1086 Internet organizations, except as needed for the purpose of 1087 developing Internet standards in which case the procedures for 1088 copyrights defined in the Internet Standards process must be 1089 followed, or as required to translate it into 1091 Internet Draft � Expires May 2002 21