CCAMP Working Group S. Ansorge Document: draft-ansorge-ccamp-lmp-sonet-sdh-00.txt D. Papadimitriou Category: Internet draft G. Grammel Expires: May 2002 J. Jones Alcatel J. Lang Calient November 2001 LMP Extensions for Sonet and SDH draft-ansorge-ccamp-lmp-sonet-sdh-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt 1. Abstract This memo is a companion document to [LMP] detailing Sonet and SDH specifics. This document extends current definition of LMP with respect to standard SDH and SONET features. It provides an overview of different SONET/SDH interface capabilities, standard SONET/SDH features and functions and defines LMP protocol extension to be used with SONET/SDH interfaces. In addition, it considers a relationship description which SONET/SDH features mentioned in this document are supported by LMP and GMPLS signaling respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Internet draft û Expires May 2002 1 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 2. Introduction This memo defines the specific Sonet/SDH extension to LMP (see [LMP]) in order to provide the operational and practical needs with respect to some mechanisms currently covered in this protocol such as Link Verification and Link Property Correlation. Thereafter, in the scope of SDH/Sonet link management, this memo proposes enhancing these functions by defining the required LMP extension to provide: - Enhanced Link Verification using the J0 Test Message - Enhanced Operational Link Status request and Fault Localization by enabling SDH/Sonet Supervision capabilities in the ChannelStatus message - Enhanced Link Property Correlation (Link Summarization) procedure by enabling the exchange of the link protection capabilities including Linear and Ring protection For this purpose this memo first review the Sonet/SDH equipment capabilities to be considered by the LMP extensions (Section 3) in order to improve the Link Verification procedure using different kind of Sonet/SDH equipment. Section 4 summarizes the Sonet/SDH supervision capabilities in order to extend the ChannelStatus field included in the ChannelStatus message. The next sections (Section 5 to 7) detail the mapping between the Sonet/SDH capabilities and the LMP protocol extensions. 3. SONET/SDH Equipment capabilities This section briefly summarizes the SONET/SDH equipment capabilities to be considered for LMP extension purposes. 3.1 SONET/SDH layer functions The SONET/SDH signal frame is decomposed in Section/Regenerator Section (RS) and Line/Multiplex Section (MS) and payload. The payload may carry multiple paths whereby each path might be subject to pointer processing. The Section/RS, Line/MS and Path are treated as separate layers. Several functions are defined, in particular: - Trail Termination (TT) function: applicable whenever the layer is terminated and generated. Section/RS TT terminates and generates the Section/RS trail, Line/MS_TT terminates and generates the Line/MS trail. This function is contiguously sending out a signal. - Adaptation function: applicable between layers to map client layer signals into layer frame structure. If no client signal is applicable a defined signal shall be used. The adaptation function can coexist only with a TT function. - Supervisory Trail Termination (STT) function: applicable when the layer is not carrying user traffic. In this case the function generates a valid signal that can be supervised from the other side. Internet Draft û Expires May 2002 2 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 - Path Overhead Monitoring (POM) function: applicable when the layer is carrying user traffic. This function is used to monitor user traffic and might be used to determine the path state. 3.2 Trail Trace Identifier in SONET/SDH Basically SONET/SDH link verification is provided in-band using Trail Trace Identifiers (TTI). At the Section/RS layer this function is implemented by using the J0 byte, on higher order paths by using the J1 byte and on lower order paths by using the J2 byte. When a trace mismatch occurs an identifier (Trace Identifier Mismatch - TIM) is generated: an alarm raised on disagreement on expected and received TTI. See Appendix 1 for more details on TTI using J0. 3.3 Other SONET/SDH capabilities 3.3.1 Line/MS capabilities Line/MS Terminating Equipment (LTE) equipment terminates and generates the Section/RS and Line/MS overhead. Other equipment could be one of the following with respect to the TTI function: - Section Generating Equipment (SGE): As long as the link is not allocated the SGE shall transmit a defined signal (like supervisory unequipped signal) which includes at least J0. Once the link is allocated the SGE function is disabled and the section monitoring function might be enabled (non intrusive). - AIS generating Equipment (AGE): As long as the link is not allocated the AGE shall emit a defined AIS signal with valid SDH/SONET frame and all ô1ö in the payload. This is a special form of SGE without support of valid J0 generation. - Section Monitoring Equipment (SME): As long as the link is allocated the end to end path is monitored in both directions on received and transmitted J0. The bi-directional function is only mandatory on network border nodes. The unidirectional function is optional at receiver side of intermediate nodes to determine the path state - SDH/SONET Extension LMP-capable nodes: such equipment is treated like STE as either J0 or DCC bytes shall be accessible for Link Verification purposes. 3.3.2 Multiplexing capabilities Three types of multiplexing capabilities can be considered: - Fixed multiplexer: In this case the adaptation function (multiplexing) is not modifiable - Flexible multiplexer: In this case the multiplexing scheme can be adapted to the payload need, e.g. an AUG4 can be used for an AU4- 4c or 4 times AU4. This is done using the standard multiplexing scheme (multiple of 4) - Transparent multiplexer: In this case the multiplexing function does not take care on the position and payload itself. Any multiple of element types at any position is supported. Internet Draft û Expires May 2002 3 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 3.3.3 Concatenation capabilities Considerations about Contiguous Concatenation are covered in [GMPLS- SONET-SDH] and [GMPLS-SONET-SDH-EXT]. 3.3.4 Monitoring capabilities Three monitoring types are defined for SDH/Sonet equipment: - Supervisory: Monitors an unallocated link or path state based on the active Supervisory TT at the other end - Non intrusive: Monitors an allocated link or path state based on end to end TT information - Inherent: Monitors whether the signal can be determined and is mainly based on the adaptation function 3.3.5 Loopback capabilities In addition SDH/SONET ports provide loopback functions. Two loopback types are defined: - Line/MS loopback: provides a loopback capability closest to the physical line. The received signal is directly looped back to the sender via the transmit port. The transmitted signal from the system is preempted by the loopback signal. This feature might be used for link verification. - Terminal loopback: provides a loopback capability closest to the physical line back to the system. The transmit signal is directly looped back to the system via the receive port. The line receiving signal is preempted by the loopback signal. This feature might be used to test a connection. 3.3.6 Protection capabilities See ITU-T G.841 for protection capabilities. 4. Sonet/SDH Supervision Capabilities Sonet/SDH Supervision covers Continuity, Connectivity, Signal Quality and Alignment Supervision. These are briefly summarized in the next paragraphs of this section. 4.1 Continuity supervision Continuity supervision refers to the integrity of the continuity of a channel. This is performed by monitoring the presence/absence of the channel information. The monitoring process can check for the whole information (e.g. LOS at the physical layer) or a specific mandatory part of it (e.g. multiframe indication for SDH Tandem Connection Monitoring - TCM). At the path layer a replacement signal might be generated by an open connection matrix (e.g. Unequipped signal for SDH). The detection of this replacement signal indicates the loss of continuity. Internet Draft û Expires May 2002 4 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 4.1.2 Loss Of Signal (LOS) LOS signal supervision is used at the physical layer. Detection of "incoming signal absent" occurs when the incoming power level at the receiver has dropped to a level corresponding to a high error condition. 4.1.3 Unequipped (UNEQ) The Unequipped defect (UNEQ) shall be detected if N consecutive frames contain the unequipped activation pattern in the unequipped overhead. The UNEQ defect shall be cleared if in N consecutive frames the unequipped deactivation pattern is detected in the unequipped overhead. Note that strictly speaking Unequipped defect is only defined for paths and not for Section/RS or Line/MS trails. 4.1.4 TC Loss of Tandem Connection (LTC) The function shall detect for the presence/absence of the tandem connection overhead in the TCM overhead by evaluating the multiframe alignment signal in the TCM multiframe overhead. The loss of tandem connection defect (LTC) shall be detected if the multiframe alignment process is in the Out Of Multiframe (OOM) state. The LTC shall be cleared if the multiframe alignment process is in the In Multiframe (IM) state. 4.2 Connectivity Supervision Connectivity supervision monitors the integrity of the routing of the trail between sink and source. Connectivity is normally only required if the layer provides flexible connectivity, both automatically or manually (e.g. static configuration). The connectivity is supervised by attaching a unique identifier at the source. If the received identifier does not match this expected identifier a connectivity defect has occurred. 4.2.1 Trace Identifier Mismatch (TTI) and Processing See Section 3.3. 4.2.2 Loss of Sequence defect (SQM) SQM shall be detected if the accepted sequence number does not match the expected Sequence number. SQM shall be cleared if the accepted sequence number matches the expected sequence number. 4.2.3 Loss of Alignment (LOA) LOA shall be detected if the alignment process cannot perform the alignment of the individual VC-4s to a common multiframe start (e.g. LOA is activated if the differential delay exceeds the size of the alignment buffer). Notice that LOA is the generic defect term Internet Draft û Expires May 2002 5 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 referring to loss of frame (LOF), Loss Of Multiframe (LOM) or Loss Of Pointer (LOP). We refer to Appendix 2 for more details on LOA. 4.3 Signal Quality supervision Signal quality supervision enables monitoring the performance of a trail. If the performance falls below a certain threshold this might activate a defect. Details one excessive errors (EXC) and degraded signal (DEG) are covered in Appendix 3. 4.4 Alignment Supervision Alignment supervision checks that the frame and frame start can be correctly recovered. The specific processes depend on the signal/frame structure and may include: û frame/multiframe alignment û pointer processing û alignment of several independent frames to a common frame start in case of inverse multiplexing If one of these processes fails a related Loss Of Alignment (LOA) shall be activated. 4.5 Maintenance Supervision Maintenance signal supervision is concerned with the detection of maintenance indications in the signal. 4.5.1 Alarm Indication Signal (AIS) If N consecutive frames contain the AIS activation pattern in the AIS overhead, an AIS failure is detected. The AIS defect shall be cleared if N consecutive frames contain the AIS deactivation pattern in the AIS overhead. For SDH MSn, the MS-AIS is transported over K2 byte while for VC3/VC4 the AU-AIS is transported over the H1, H2 bytes. 5. Mapping SDH/SONET capabilities to LMP functions 5.1 Link Verification 5.1.1 Contiguous Link Verification Usually, the link capabilities and activation shall be provided in the DATA LINK objects of the Link Summary message (e.g. LTE, STE, SGE, AGE, POM, etc). For instance, when considering STE or LTE equipment, J0 is always inserted and monitored on both sides of the link. The following procedures can be defined when using J0 test message: - LTE equipment: As J0 is contiguously transmitted on the link, the Link Summary message shall contain the received and transmitted J0 Internet Draft û Expires May 2002 6 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 on the port. In case of agreement (capability negotiation both sides are LTE) the standard TTI (Trail Termination Identifier) functions are activated (monitor received J0) and raise a TIM alarm in case of disagreement. - SGE equipment: As J0 is contiguously transmitted on the link as long as the link is not allocated Link Summary message shall contain the received and transmitted SGE J0. The activated SGE function shall be indicated in the link summary message. - POM (Path Overhead Monitoring) equipment: As J0 is contiguously monitored on both sides of the link as long as the link is allocated the channel status message shall contain the received and transmitted J0 for verification. 5.1.2 Out-of-band J0 Test Message Capable of communicating using standard J0 byte as defined in ITU-T G.707 for section trace monitoring. In this case, the Test message is not transmitted using the J0 byte (i.e. over the Data Link) but sent over the Control Channel and correlated for consistency check to the received J0 pattern. In that case the Interface ID determines the interface over which the standard J0 byte are transmitted in- band. This feature is thus provided to accommodate Link Verification when using legacy Sonet/SDH LTE equipment. In order to get the mapping between the Interface ID over which the J0 Test message is sent and the J0 pattern sent in-band, one must provide the correlation between this pattern and the J0 Test message. 5.2 Link Verification 5.2.1 LTE and STE transparent equipment (Contiguous) The entire link verification procedure for LTE and STE is based on standard SDH/SONET Trail Trace Identifier (TTI) functions in all cases here contiguously generated and terminated on both link sides. The entire link verification (BeginVerify, Test, VerifyEnd, and corresponding acknowledgements) procedure as described in [LMP] is replaced by exchanging transmitted and received TTI within the DATA LINK object in the LinkSummary message. In case of agreement as a result of Link Summary message exchange the received/negotiated TTI is used as expected TTI and TIM alarm is activated. 5.2.2 Fully transparent equipment (Supervisory) Link verification for fully transparent equipment must distinguish between equipment capable to provide Supervisory Trail Termination function and/or path monitoring function. For equipment providing Supervisory Trail Termination function the same rules applies as described above (see Section 5.2.1) as long Internet Draft û Expires May 2002 7 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 the path is not allocated for user traffic. As soon the path is allocated for user traffic the Supervisory Trail Termination function is deactivated and user traffic can pass. Optionally the user traffic can be monitored for path state validation. For equipment not capable to provide Supervisory Trail Termination function the J0 based link verification procedure cannot be applied. Those links can only be tested with loopback capabilities (see Section 5.3). 5.2.3 LTE terminating equipment (Out-of-band) An LTE exchanging within its overhead a Sonet/SDH Section/RS Trace over the J0 byte (while Path tracing uses J1 or J2 byte). If the trace exchanged over the out-of-band Test message does not match the in-band Section/RS Trace message, the node report the mismatch condition (TIM). 1. Test Message (MsgType = 10) The Test message is transmitted over the control channel; the matching with the Section/RS trace message is used to verify its physical connectivity. This message is transmitted as an IP packet with payload format as follows: ::= The above transmission order MUST be followed. Note that this Test Message is sent over a control channel and NOT over a data link and is used to request a node to extract from one or more data links for a specific trace value at a given interface ID. The local (transmitting) node sends a given Test message periodically (at least once every VerifyInterval ms) on the corresponding data link until (1) it receives a correlating TestStatusSuccess or TestStatusFailure message on the control channel from the remote (receiving) node (2) or all active control channels between the two nodes have failed. The remote node will send a given TestStatus message periodically over the control channel until it receives either a correlating TestStatusAck message or an EndVerify message is received over the control channel. 2. TestStatusSuccess Message (MsgType = 11) The TestStatusSuccess message is transmitted over the control channel and is used to transmit the mapping between the local Internet Draft û Expires May 2002 8 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 Interface Id û In-band Section/RS Trace and the Interface Id û Out- of-band Section/RS Trace that was received in the Test message. ::= The above transmission order MUST be followed. The contents of the REMOTE_INTERFACE_ID object MUST be obtained from the corresponding Test message being positively acknowledged. The Trace Message (received through the control channel and expected from the data link arenÆt exchanged in case of test success) 3. TestStatusFailure Message (MsgType = 12) The TestStatusFailure message is transmitted over the control channel and is used to indicate that the Section/RS trace message (exchanged over data links) was not received. ::= The above transmission order MUST be followed. 4. TestStatusAck Message (MsgType = 13) The TestStatusAck message is used to acknowledge receipt of the TestStatusSuccess or TestStatusFailure messages. ::= The above transmission order MUST be followed. The contents of the MESSAGE_ID_ACK object MUST be obtained from the TestStatusSuccess or TestStatusFailure message being acknowledged. 5. TestMismatch Message (MsgType = 21) The TestStatusFailure message is transmitted over the control channel and is used to indicate a Section/RS Trace Mismatch between the in-band and the out-of-band Section/RS Trace. ::= The above transmission order MUST be followed. 6. TestMismatchAck Message (MsgType = 22) The TestMismatchAck message is used to acknowledge receipt of a TestMismatch message. Internet Draft û Expires May 2002 9 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 ::= The above transmission order MUST be followed. Additional Object Class: TRACE MESSAGE Class (Class = 22) See Section 7.1. For bi-directional links two Trace Messages are exchanged one for receive direction and one for the transmit direction (TRANSMIT TRACE and RECEIVE TRACE MESSAGE, respectively). 5.3 Loopback function 5.3.1 Description With AGE equipment, no overhead can be monitored or generated on a Line/MS, the node must therefore provide Line/MS loopback function. A sender is requesting a Line/MS loopback for a certain time to test the Line/MS and reading its own generated data. This request is used to indicate the direction of the loopback; either towards the Line/MS or towards the system and therefore not used for layers. If the sender is of SGE type, it can verify its transmitted signal with respect to the signal on the receive port. If both signals match, the corresponding ports are wired in the right manner. To avoid ambiguous interpretation of loopback signals a node shall support only one loopback function at a time. Consequently, on time- by-time basis, these capabilities are mutually exclusive. Moreover, the loopback trigger must hence always direct to a single port. 5.3.2 Loopback Trigger When Loopback Trigger function is used, the sender does not wait for a test message to be received from remote side since the receiving port internally generates the test message. To support AGE-AGE links a test generator shall be applicable at each node to test links. The test generator equipment must be cross- connected to the desired port for testing. Loopback functions can be requested on single interface base by the LMP neighbor. This operation is based on LinkVerify message exchange without using the Test, TestStatusSuccess, TestStatusFailed, and TestStatusAck messages. BeginVerify objects must be extended to invoke loopback activation on neighbor side. The VerifyEnd objects must be extended to release the loopback function. Internet Draft û Expires May 2002 10 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 While the loopback is active the initiator MUST verify its receiving signal side whether it matches with the emitting side. Basis for this validation can be standard Sonet/SDH LTE and STE function validating the received TTI. 5.4 Contiguous Path monitoring Even when interface (or path) is allocated for user traffic, Sonet/SDH provides means to monitor the path by using a path monitoring function. Activation of path monitoring function is usually beside the responsibility of signaling based on specific service characteristics. It can be activated by the ChannelStatus messages. Nevertheless once the path monitoring function is activated it can be used for LinkVerify and ChannelStatus purposes by exchanging the ingress and egress monitored TTI. ChannelStatus messages will activate/deactivate SGE or AGE functions. 6. Link Property Correlation 6.1 Multiplexing Capabilities Multiplexer alignment (except for transparent multiplexers) implies that the payload structure of both ports must be aligned to avoid pointer processing alarms. Therefore the multiplexing scheme and capabilities shall be included in the DATA LINK object (Class = 17) of the Link Summary message. In particular: - Fixed multiplexer : Capability Min = Max - Flexible multiplexer : Capability Min < Max - Transparent multiplexer: Capability Min = ôinfinite valueö = Max 6.2 Protection Link protection including Linear and Ring protection capabilities can be exchanged between LMP neighbors by using LinkSummary message. Linear protection can be take one (or more than one) of the following configuration: - Linear 1+1 dedicated protection - Linear 1:1 dedicated protection - Linear 1:N shared protection Ring protection can be configured using the following capabilities when available: - Line/MS-DPRing : Dedicated MS/Line protection ring - Line/MS-SPRing : 2-fiber MS/Line Shared protection ring - Line/MS-SPRing : 4-fiber MS/Line Shared protection ring - Path-DPRing : Dedicated Path protection ring - Path-SPRing : Shared Path protection ring 7. LMP protocol extensions Internet Draft û Expires May 2002 11 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 7.1 Link Verification To support contiguous Link Verification the following new object types are defined (here TRACE refers to TTI): TRACE MESSAGE Class (Class = 22) - TRANSMIT TRACE (C-Type = 1) 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Trace Type | Trace Flags | Trace Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Trace Message (16 bytes) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This object is non-negotiable (N = 0). Trace Message Type: 8 bits Defines the type of the test message includes: 1 û Sonet Section and SDH RS Trace (J0 Byte) 2 û Sonet STS-SPE and SDH HO Path Trace (J1 Byte) 3 û Sonet VT and SDH LO Path Trace (J2 Byte) There are no other types for SDH/Sonet Trace Flags: 8 bits Describe the scope of the TTI to which it applies 0x00 Unknown 0x01 Trail Termination (TT) 0x02 Supervisory Trail Termination (STT) 0x04 Path Overhead Monitor (POM) Trace Length: 16 bits The Length in bytes of the trace message provided. Trace Message: Transmitted Trace message. The valid length and value combinations are determined by the specific technology (e.g., Sonet or SDH). The message MUST be padded with zeros to a 32-bit boundary, if necessary. - RECEIVE_TRACE (C-Type = 2) 0 1 2 3 Internet Draft û Expires May 2002 12 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Trace Type | Trace Flags | Trace Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Trace Message (16 bytes) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LinkSummary Message (MsgType = 14) used to synchronize the Interface Ids and correlate the properties of the TE link. The format of the LinkSummary message is as follows: ::= [] [] [...] Moreover, the DATA LINK Object (Class = 17, C-Type = 1 and 2) Flags field must include the following additional values: 0x01 Interface Type (see [LMP]) 0x02 Allocated Link (see [LMP]) 0x04 Contiguous Link Verification 0x08 Supervisory Link Verification 0x10 Path Monitoring To enable the transport of the Test Message over the control channel, the BEGIN_VERIFY object (Class = 13, C-Type = 1), the Verify Transport Mechanism field (16 bits) must include an additional value. More precisely, Verify Transport Mechanism: 16 bits This defines the transport mechanism for the Test Messages. The scope of this bit mask is restricted to each link encoding type. The local node will set the bits corresponding to the various mechanisms it can support for transmitting Test messages. The receiver chooses the appropriate mechanism in the BeginVerifyAck message. For Sonet/SDH Encoding Type, the following flags are defined: 0x01 J0-16 0x02 DCCS 0x04 DCCL 0x08 J0-16 (TestMessage over Control Channel) 7.2 Loopback Verification Internet Draft û Expires May 2002 13 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 The Flag field (16 bits) defined in the BEGIN_VERIFY_object (Class = 13, C-Type = 1) shall be extended to cover link loopback function: Flags: 16 bits The following flags are defined: 0x01 Verify all Links If this bit is set, the verification process checks all unallocated links; else it only verifies new ports or component links that are to be added to this TE link. 0x02 Data Link Type If set, the data links to be verified are ports, otherwise they are component links 0x04 Loopback If set, the data link loopback function is activated. The loopback function is deactivated in case of following events: a) at the end of the verify interval (VerifyDeadInterval) b) on receipt of EndVerify message c) when the port is allocated for user traffic Moreover VerifyDeadInterval and Verify_Transport_Mechanism fields in the BEGIN_VERIFY_ACK (Class = 14, C-Type = 1) fields must be configured accordingly 7.3 Supervision The ChannelStatus message is sent over the control channel and is used to notify an LMP neighbor of the status of a data link. The ChannelStatus (31-bit) field defined as the CHANNEL_STATUS Object (Class = 18, C-Type = 1) of the ChannelStatus Message includes the following additional values in order to include Sonet/SDH supervision capabilities: For Continuity Supervision purposes (see Section 4): Value Status Condition ----- ---------------- 5 Loss Of Signal (LOS) 6 Unequipped (UNEQ) 7 Unequipped Available (UNEQa) 8 Unequipped Unavailable (UNEQu) 9 Automatic Report Control (ARC) 10 Loss Of Tandem Connection (LTC) For Connectivity Supervision purposes (see Section 4): Internet Draft û Expires May 2002 14 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 Value Status Condition ----- ---------------- 16 Trace Identifier Mismatch (TIM) 17 Loss of Sequence (SQM) 18 Loss of Alignment (LOA) 19 Loss of Frame (LOF) 20 HOVC Loss Of Multiframe (LOM) 21 Loss of Pointer (LOP) For Maintenance Supervision purposes (see Section 4): Value Status Condition ----- ---------------- 22 MS/Line AIS (AIS) 7.4 Link Protection As mentioned in Section 3.3, for protection purposes the standard MSP/APS protocol (as defined in G.841) is used. In order to exchange protection parameter during the Link Property Correlation procedure, links must be identified by (component) Interface Ids and protection group by Protection Group Ids. This Protection Group Id includes the references to the links, whether a link is to be considered primary or secondary (refer to as the Protection Status (PS) and a Link Priority for 1:N protections purposes. The following object is exchange in the LinkSummary message. After exchanging this message, the procedure described in Section 4 of [LMP] applies. 7.4.1 LINEAR PROTECTION Class LINEAR PROTECTION Class (Class = 23) - C-Type = 1 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protection Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Linear Prot. | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PS | Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // ... // | | Internet Draft û Expires May 2002 15 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PS | Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Protection Group ID: 32 bits Identifies the Protection Group Linear Protection Type: 8 bits 0x00 Unknown 0x01 Linear 1+1 dedicated protection 0x02 Linear 1:1 dedicated protection 0x04 Linear 1:N shared protection Priority: 8 bits Defines the priority levels of the link included in 1:N shared protection groups. Default value is 0. Protection Status (PS): 8 bits 0x00 Unknown 0x01 Primary (Working) 0x02 Secondary (Protecting) Reserved fields: must be zeroed when sent and ignored when received 7.4.2 RING PROTECTION Class RING PROTECTION Class (Class = 24) - East Node: C-Type = 1 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protection Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ring Protection| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | East Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PS | Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // ... // | | Internet Draft û Expires May 2002 16 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PS | Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - West Node: C-Type = 2 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protection Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ring Protection| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | East Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PS | Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // ... // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PS | Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Protection Group ID: 32 bits Identifies the Protection Group Interface ID: 32 bits (see [LMP]) Ring Protection Type: 8 bits 0x00 Unknown 0x01 Line/MS-DPRing 0x02 Line/MS-SPRing (2-fiber) 0x04 Line/MS-SPRing (4-fiber) 0x08 Path-DPRing 0x10 Path-SPRing Priority: 8 bits Defines the priority levels of the link included in 1:N shared protection groups. Default value is 0. Protection Status (PS): 8 bits 0x00 Unknown Internet Draft û Expires May 2002 17 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 0x01 Primary (Working) 0x02 Secondary (Protecting) Reserved fields: must be zeroed when sent and ignored when received 7.5 Multiplexing Capabilities To be covered in a future release. 8. Security Considerations This document does not imply additional security considerations to the one already defined in [LMP]. 9. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Lang, J. et al, ôLink Management Protocol v1ö, Internet Draft, draft-ietf-ccamp-lmp-02.txt, October 2001 10. Acknowledgments The authors would like to thank Bernard Sales, Emmanuel Desmet, for their constructive comments and inputs. 11. Author's Addresses Stefan Ansorge Alcatel SEL AG E-mail: Stefan.ansorge@alcatel.de Gert Grammel Alcatel Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-7060 Email: gert.grammel@netit.alcatel.it Jim Jones Alcatel 3400 W. Plano Parkway, Plano, TX 75075, USA Phone: +1 972 519-2744 Email: Jim.D.Jones1@usa.alcatel.com Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: Dimitri.Papadimitriou@alcatel.be Internet Draft û Expires May 2002 18 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 Jonathan P. Lang Calient Networks 25 Castilian Drive Goleta, CA 93117, USA Email: jplang@calient.net 12. Appendix 1: Trail Trace Identifier (TTI) A Trail Trace Identifier (TTI) is defined as a 16-byte frame structure. The first byte is a header byte, which includes the result of a CRC-7 calculation over the previous frame. The following 15 bytes are used for the transport of 15 T.50 characters required for the Section Access Point Identifier (SAPI). The ones used for the Test Message. Moreover the bit 1 of each byte (of the 16 byte frame structure) is the trace identifier frame alignment signal (value = 1000 0000 0000 0000). The structure for the J0 16 byte frame: 0 1 2 3 4 5 6 7 1 1 x x x x x x x <= CRC-7 2 0 - - - - - - - 3 0 - - - - - - - 4 0 - - - - - - - . . - - - - - - - 16 0 - - - - - - - A TTI is generated by the trail termination functions and supervisory trail termination functions. As mentioned before the trail termination function is contiguously sending out a valid signal and a stable Trail trace identifier. The supervisory trail termination function is sending out a valid signal with a stable trail trace identifier as long the line or path is not allocated for user services. Derived Management functions on TTI for the control plane are: - Send TTI: provision the emitted TTI - Received TTI: retrieve the received TTI - Expected TTI: check the received TTI with an expected TTI - Trace Identifier Mismatch (TIM): an alarm raised on disagreement on expected and received TTI Appendix 2 û Loss Of Alignment (LOA) LOA is the generic defect term referring to Loss Of Frame (LOF), Loss Of Multiframe (LOM) or Loss Of Pointer (LOP). The following paragraphs describes each of these defects: Loss Of Frame (LOF) For STMn/STSn signals, if the out-of-frame state persists for 3 milliseconds, a loss of frame (LOF) state shall be declared. Internet Draft û Expires May 2002 19 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 Once in a LOF state, this state shall be left when the in-frame state persists continuously for 3 milliseconds. HOVC Loss Of Multiframe (LOM) If the multiframe alignment process is in the out-of-multiframe state and the H4 multiframe overhead byte is not recovered within N ms (not configurable and in the range 1 ms to 5 ms)), a LOM defect shall be declared. Once in a LOM state, this state shall be exited when the multiframe is recovered. Loss of Pointer (LOP) A LOP is declared if the pointer value cannot be interpreted in the right manner. This might be due to illegal values (out of range), or due to high frequency of value changes. Appendix 3 - Excessive error (EXC) and Degraded signal (DEG) Excessive error and degraded signal defects are to be detected according to the following process: - An excessive error (EXC) shall be detected if the equivalent BER exceeds a preset threshold of 10^(-x), x = 3 , 4 or 5. The excessive error defect shall be cleared if the equivalent BER is better than 10^(-x-1). - A degraded signal (DEG) shall be detected if the equivalent BER exceeds a preset threshold of 10^(-x), x = 5, 6, 7, 8 or 9. The degraded signal defect shall be cleared if the equivalent BER is better than 10^(-x-1). A DEG defect can be detected in æburstyÆ mode in case N consecutive seconds the Error Rate is greater than a provision-able threshold. SONET uses EXC detector types, while most AU-4 based SDH uses Alternative DEG detector types. Internet Draft û Expires May 2002 20 draft-ansorge-ccamp-lmp-sonet-sdh-00.txt November 2001 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Internet Draft û Expires May 2002 21