CCAMP Working Group W. Bigos (AGH) Internet Draft S. Ansorge (Alcatel) Category: Informational G. Grammel (Alcatel) Expiration Date: May 2003 F. Tetzlaff (T-Systems) D. Papadimitriou (Alcatel) F.-J. Westphal (T-systems) November 2002 Applicability of LMP (and LMP-WDM) draft-papadimitriou-ccamp-lmp-ls-applicability-01.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. 1. Abstract Integration of Generalized MPLS-capable SONET/SDH networks in existing backbone environments has generated the need to determine inter-working capabilities between nodes interconnected by both SONET/SDH and non-SONET/SDH overhead terminating networks. This is particularly the case for critical functions and applications such as the ones provided by the Link Management Protocol [LMP] and its WDM extensions [LMP-WDM]. In this context, this document describes the applicability of their respective functions and illustrates them through several inter-connection architectures. D.Papadimitriou et al. Expires May 2003 1 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 2. Conventions used in this document 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]. In addition the reader is expected to be familiar with the terminology described in [LMP], [LMP-WDM] and [GMPLS-SIG]. 3. Introduction Today nearly all regional-, metro- and backbone transmission networks are equipped with SONET/SDH devices. These networks are managed by manual operations via a centralized management system. Most of the current SONET/SDH devices do either not provide the required capability for GMPLS to operate (also referred to as legacy SONET/SDH nodes) or are not capable to support the GMPLS protocol set required to act as LSRs (also referred to as GMPLS-capable nodes). One migration scenario for the near future may consist out of a small GMPLS capable sub-network which is initially build out of a few GMPLS capable nodes only and the GMPLS-capable nodes are interconnected via manually established connections over a legacy SONET/SDH sub-network. The operation and maintenance in legacy SONET/SDH environments are well defined as well as their interaction with the management plane. For the GMPLS-capable nodes exist the Link Management Protocol [LMP] and appropriate enhancements like the ones proposed in [LMP-SONET-SDH-TEST] and [LMP-SONET-SDH]. The missing link is the communication between and across both sub- networks. This document proposes LMP (and LMP-WDM) as the protocol for communicating information between and across non-LMP capable and LMP-capable device(s). In turn, this enables to build a logical GMPLS network on top of existing legacy environments and to fulfill the requirements of different migration scenarios. The Link Management Protocol [LMP] is being developed as part of the GMPLS protocol suite to manage traffic engineering (TE) links. LMP currently consists of four main functions, of which, the first two functions are mandatory and the last two are optional: 1. Control channel management 2. Link property correlation 3. Link verification 4. Fault management Control channel management is used to establish and maintain IP connectivity between adjacent nodes. This is done using a Config message exchange followed by a lightweight keep-alive message exchange. Link property correlation is used to aggregate multiple data links into a single TE Link and to synchronize the link properties. Link verification is used to verify the physical connectivity of the data links and to exchange the data link Ids. D.Papadimitriou et al. Expires May 2003 2 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 Fault management is used to localize failure points and consequently suppress alarms on subsequent points in both opaque and transparent networks. In [LMP-SONET-SDH], [LMP-SONET-SDH-TEST] and [LMP-BOOT], we define SONET/SDH technology specific information needed when running LMP. Specifically, we define the SONET/SDH test procedures used for Link and LSP verification and link property correlation. We also propose a Link verification procedure using loopback capable SONET/SDH interface. This document describes two generic SONET/SDH node inter-connection cases and the applicability of LMP between these edge devices. In the first case (described in Sections 4), LMP-capable SONET/SDH edge devices are connected by a legacy SONET/SDH network that terminates the section overhead and none of its node is LMP-capable (the LMP session is provided between the client SONET/SDH devices only). In the second case (described in Section 7), the LMP (and LMP-WDM) capable SONET/SDH edge devices are connected through a non-SONET/SDH network that does not terminate the section overhead at its edges. Moreover, one considers that the edge devices of the non-SONET/SDH network are LMP-WDM capable. Several reference architectures and scenarios (see Section 4) illustrate these two generic inter- connection cases. From these, this document deduces (in Section 5 and 6) the applicability of the LMP functions and their detailed operations. 4. Scope and Covered scenarios Depending on the configuration of the underlying legacy SONET/SDH network, there are many different possible migration scenarios from legacy configuration to networks, which are completely GMPLS capable. Some criteria to distinguish between different scenarios are listed here: - For protection purposes it is possible to connect two GMPLS capable nodes via a protected SONET/SDH connection. . - Another way is to protect the interconnection of the GMPLS capable sub-network via a further interconnection within the legacy sub-network, which is disjoint with the first and may be selected in the case of an fault. The GMPLS capable nodes have to take care about protection switching time within the legacy sub-network. - A further distinction could be made by SONET/SDH leased lines configured with or without automatic laser shutdown. A unidirectional link failure results into bi-directional link failure. - And finally the legacy SONET/SDH sub-networks in between the GMPLS capable sub-network can be operated unidirectional or bi- directional. Thus this document covers 3 migration scenarios. Each of them is described in detail here below: D.Papadimitriou et al. Expires May 2003 3 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 Scenario 1: Reference architecture LMP Network <---- --- non-LMP Sub-Network --- ---> LMP Network | | | | | | SONET/SDH Net <-- --> SONET/SDH Sub-Net <-- ---> SONET/SDH Net Edge Node(X) Node(1) ---- Node(N) Edge Node(Y) | | | | | | <---------------------- LMP -----------------------> Here one assumes Path OH transparency over the SONET/SDH sub- network, thus the non-LMP Sub-Network includes only MS/Line (or RS/section) Terminating equipment and provides only path trail service. The path trail between the LMP capable (GMPLS capable) SONET/SDH sub-network is terminated at edge Node(X) and edge Node(Y). The SONET/SDH leased line between node (1) and node (N) of the legacy SONET/SDH sub-network is unprotected, without automatic laser shutdown and bi-directional. The considered SONET/SDH overhead information is related to the SONET/SDH path between Node(X) and Node(Y). Without further restrictions it may be necessary to define a kind of bundling of trails (and not links) between the LMP adjacencies (Node (X) and Node (Y)). The specific aspects related to trail discovery and bundling are addressed in Section 6. Scenario 2 û Reference Architecture This scenario can be considered as a particular case of the previous one where Node(X) and Node(Y) are inter-connected through a legacy SONET/SDH sub-network managed by an Element Management System (EMS). In turn, this EMS represents from the edge node viewpoint, an LMP- capable adjacent node hiding the non-support of LMP within the legacy sub-network. LMP Network <-- --- non-LMP Sub-Network --- --> LMP Network | | | | | | SONET/SDH Net <-- --> SONET/SDH Sub-Net <-- --> SONET/SDH Net Edge Node(X) Node(1) ---- Node(N) Edge Node(Y) | | | | | | <---------LMP---------> EMS <--------LMP--------> In such conditions, potential problem may come from the processing time of the LMP messages at the EMS. This, in addition to the time D.Papadimitriou et al. Expires May 2003 4 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 it takes to correlate the information received from the edge LMP sessions defined between Node(X) and EMS and between EMS and Node(Y), with the one received through its proprietary interface to the non-LMP sub-network nodes). It may thus be advisable to combine both LMP Sessions with an edge- to-edge LMP session in order to achieve the following LMP adjacencies and sessions: LMP Network <-- --- non-LMP Sub-Network --- --> LMP Network | | | | | | SONET/SDH Net <-- --> SONET/SDH Sub-Net <-- --> SONET/SDH Net Edge Node(X) Node(1) ---- Node(N) Edge Node(Y) | | | | | | | | | <---------LMP-------> EMS <-------LMP-------> | | | <--------------------------LMP------------------------> The purpose of this edge-to-edge LMP session (between the SONET/SDH legacy sub-network edge nodes, e.g. Node(X) and Node(Y)) is somehow less obvious. Here, the value added by this edge-to-edge LMP session in the above architecture would (only) help to determine whether the failure is located inside or outside the SONET/SDH sub-network but when located inside if the defect is localized between edge nodes or internal to the sub-network (i.e. between Node(1) and Node(N)). Scenario 3 û Reference Architecture In this architecture, one assumes that the SONET/SDH edge Node(X) and Node(Y) maintain an LMP session with the edge nodes of the legacy SONET/SDH sub-network through the use of an EMS system (EMS1 for Node(X) and EMS2 for Node(Y)). However, since LMP continuity is not available between edge Node(X) and Node(Y) a complementary edge-to-edge LMP session between Node(1) and Node(N) should normally allow to bridge their local instances with the EMS systems located at the edges. In this context, the following configuration can be considered: LMP Network <------ LMP Sub-Network ------> LMP Network | | | | SONET/SDH Net <-- --> SONET/SDH Sub-Net <-- --> SONET/SDH Net Edge Node(X) Node(1) -------- Node(N) Edge Node(Y) | | | | | | | | | | | | | | | | | | EMS1 <---LMP--- <----LMP----> ---LMP---> EMS2 D.Papadimitriou et al. Expires May 2003 5 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 Here, the Element Management System (EMS) fulfilling an LMP Proxy function allows considering actions based on failure indication correlated information, if the failure is external to the SONET/SDH sub-network then either EMS1 or EMS2 will take the recovery decision under its responsibility. However, if the failure is internal to the SONET/SDH sub-network then through a dedicated message exchange between Node(1) and EMS1 (or between Node(N) and EMS2) the recovery action could still be initiated by EMS1 (or EMS2) and executed by the edge nodes Node(X) (or Node(Y), respectively). Note: (LMP) Control Channel --------------------------- In the SONET/SDH context, two signalling transport mechanisms are defined: out-of-band or in-band through the RS/Section (D1-D3) and MS/Line DCC (D4-D12) û note for OC-768 (D13-D156 is also defined) Therefore, due to the termination of the MS/Line and RS/Section at the legacy sub-network SONET/SDH nodes, one should preferably consider an out-of-band control channel. This because having an in- band control channel would imply maintaining an (LMP) control channel using the Data Communication Channel (DCC) bytes and some overhead mapping facilities to allow forwarding DCC information between neighbouring RS/Section and MS/Line trails. 5. Fault Localization Fault Management, includes Fault Detection, Fault Correlation and Fault Localization/Isolation. [LMP] provides the tools to deliver the Fault Localization/Isolation capabilities. However, he challenge compared to the canonical LMP model is that a node adjacency does not give a corresponding LMP adjacency. Moreover, labels have an associated structure relying on their multiplexing structure (see [GMPLS-SONET-SDH] and [GMPLS-OTN]). Once the local label is exchanged across an interface to its neighboring node, the value of the local label may be not significant to the neighbor node since the value used for the local label and the remote label may not necessarily be the same. This issue does not present a problem in a simple connection between adjacent nodes the timeslots are mapped 1:1 across the interface. However, once a non- GMPLS capable sub-network is introduced between these nodes (as in the above figure, where the sub-network provides re-arrangement capability for the timeslots) label association becomes an issue. These observations generate the following issues with respect to LMP: 1. Fault correlation must be provided between non-physically adjacent LMP neighbors 2. Links are not anymore symmetrical (the labels on an egress interface of the edge Node(X) are not necessarily the same at the ingress interface of the edge Node(Y) and vice versa) D.Papadimitriou et al. Expires May 2003 6 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 To enable fault correlation and isolation/localization between non- physically adjacent LMP neighbors the complete defect indication flows considered here can be summarized as follows when a unidirectional failure occurs: Node(X) <------- Subnet -------> Node(Y) Node(X) FDI ---------> Node(Y) - Forward DI (downstream) | Node(X) <-------- BDI ---------- Node(Y) û Backward DI (upstream) DI is used as a generic term to indicate a Defect indication (such as LoF, LoP or LoM depending upon the connectivity or continuity, supervision respectively). See Appendix 1 for the SONET/SDH Supervision Capabilities. The FDI is used as a generic term and refers to the Alarm Indication Signal (AIS), AIS is a signal sent downstream as an indication that an upstream defect has been detected. The BDI is used as a generic term and refers to the Remote Defect Indication (RDI). RDI is a signal sent upstream as an indication to the remote transmit end that the received end has detected an incoming trail defect or is receiving AIS. The first action to be executed between Node(X) and Node(Y) is to obtain the interface ID mapping (and label association), for this purpose one expects here to see the capability for these node to insert a J1/J2 Trace pattern sent in-band to be correlated with an out-of-band test message as described in [LMP-SONET-SDH]. Then, in order to locate the failure event, one takes advantage of the Fault isolation/localization capabilities of [LMP], which can be briefly summarized through the following flow diagram: Tx ----------------> Rx Node(i) Node(j) Rx <---------------- Tx 1. Failure detected at Node(j) Receiver (Rx) side 2. ChannelStatus message sent from Node(j) to Node(i), the latter sends an Acknowledgment message back to Node(j) upon reception 3. Correlation is performed at Node(i) (notice that once correlation and localization is performed any subsequent recovery action can be initiated) 4. ChannelStatus message sent from Node(i) to Node(j), upon reception, the latter sends an Acknowledgment message back to Node(i) Here, the expected LMP behavior can be determined from the following indications received from the transport plane overhead. Here below we analyze the following cases: D.Papadimitriou et al. Expires May 2003 7 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 Case a) Uni- or bi-directional failure within the legacy network Case b) Uni- or bi-directional failure outside the legacy network - Case b1) Downstream FDI - Case b2) Upstream FDI Case a) Uni- or Bi-directional failure within the legacy SONET/SDH sub-network Consider for instance that Node(Y) receives an FDI (and optionally, Node(Y) sends a BDI that is subsequently received by Node(X)) and wants to locate whether the failure has occurred inside or outside the SONET/SDH legacy sub-network (see Section 4 - Scenario 1, for instance). In this case, Node(Y) receiving the FDI sends a (ChannelStatus) message to Node(X), the latter after acknowledging its reception, verifies the indication received for the same trail in the upstream direction (i.e. Node(X) verifies if an defect indication has been on the corresponding receiver side) and in the downstream direction (i.e. Node(X) checks if it has received an FDI indication at one of its input ports). Then, since Node(X) has not received an FDI indication at one of its incoming or outgoing interfaces, the fault has been localized as uni-directional failure within the legacy sub-network. In this eventuality, Node(X) can perform any of the sub-sequent recovery action needed to recover the trail under failure condition. Then, Node(X) sends a (ChannelStatus) message to Node(Y) which acknowledges its reception. So, in brief, in case of unidirectional failure, the fault isolation steps are the following: 1. Node(Y): Send ChannelStatus message to Node(X) upon FDI reception and wait for ACK 2. Node(X): ACK the ChannelStatus message received from Node(Y) and perform correlation 3. Node(X): Send ChannelStatus message to Node(Y) and wait for ACK This becomes more complex when a bi-directional failure occurs: Node(X) <------- Subnet -------> Node(Y) Node(X) FDI ---------> Node(Y) û Forward DI (downwstream) Node(X) <-------- FDI Node(Y) û Forward DI (upstream) Here, both Node(X) and Node(Y) sends a (ChannelStatus) message toward Node(Y) and Node(X) respectively. After acknowledgment, both sides correlate the FDI received at their input port, and determine the bi-directionality of the failure within the legacy sub-network. Thus here, the correlation will generate a (ChannelStatus) message from node Node(X) to Node(Y). This message indicates the interface status corresponding to the one specified by the (LMP) neighboring D.Papadimitriou et al. Expires May 2003 8 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 node but also the status of the corresponding receiver interface (i.e. the one through which the FDI message is received). In order to prevent any further FDI (AIS) to be reported by Node(Y) to a supervisory system, one assumes here that once the acknowledgment (ChannelStatusAck) message is received by the sender of the ChannelStatus message, alarm reporting is suppressed. Moreover, taking into account that LMP will not generate any subsequent (ChannelStatus) Message as long as the FDI indication is received this would pace the whole process and thus avoid overflowing the control plane until the interface status recovers. Note: Automatic Laser Shutdown (ALS) ALS can be considered as a specific case of uni-directional failure generating bi-directional failure indication. Consider the following situation: Tx --- .. --- Rx - Tx1 ---x---> Rx2 û Tx --- .. --- Rx | | TE <---- FDI --- x x --- FDI ----> TE | | Rx --- .. --- Tx - Rx1 <--x---- Tx2 û Rx --- .. --- Tx The consecutive Loss of Signal defect (dLOS) at "conventional" receiver RX2 is used to shutdown the output of "conventional" transmitter TX2, which is the adjacent transmitter in the opposite direction. This in turn leads to dLOS in "conventional" receiver Rx1, which in turn shuts down "conventional" transmitter Tx1. After shutdown the output power of the transmitter shall be sufficiently low to generate dLOS at the receiver side. See [ITUT-G664] for more details on ALS and [ITUT-G783] for more detail on dLOS. Case b) Uni- or Bi-directional failure outside the legacy SONET/SDH sub-network In this case, the legacy SONET/SDH only forward the defect indication and therefore one can reasonable assume that Node(X) will detect the same indication as Node(Y). Thus the failure is located outside the SONET/SDH legacy sub-network and either an FDI or optionally a BDI is detected. Ingress incoming interface / Egress incoming interface Case b1) Downstream FDI On one hand, if Node(X) then Node(Y) receive an FDI as depicted in the following figure: Node(W) ----------- Node(X) ---- Subnet ----> Node(Y) D.Papadimitriou et al. Expires May 2003 9 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 Node(W) --- FDI --> Node(X) ---- FDI ----> Node(Y) By receiving the FDI on one of its ingress interface, Node(X) follows the canonical fault localization/ correlation procedure while Node(Y) by receiving the FDI transported over the legacy SONET/SDH sub-network follows the procedure described here below: . By receiving the ChannelStatus message from Node(Y), Node(X) correlates this information received for the corresponding ingress interface (flowing in the downstream direction) and egress interface (flowing in the upstream direction). Since a defect indication is only received at one of its ingress interfaces for the corresponding trail (from Node(W)), Node(X) sends a ChannelStatus message to Node(Y) indicating that the corresponding egress interface (toward Node(Y)) has not received any failure indication for that trail. This means that the failure is localized upstream to Node(X). Therefore, neither Node(X) or Node(Y) will perform any subsequent recovery actions for that trail as the failure is located upstream, outside to the legacy SONET/SDH network. Case b2) Upstream FDI On the other hand, if Node(Y) then Node(X) receive an FDI as depicted in the following figure: Node(X) <--- Subnet ----- Node(Y) ----------- Node(Z) Node(X) <--- FDI ----- Node(Y) <-- FDI --- Node(Z) One gives the precedence to the node receiving the FDI indication, however this does not provide any effective processing since from one side both edge nodes will either wait for each other or send the initiating fault correlation message. Thus one has to rely on the ChannelStatus message sent by Node(Y) to Node(Z) and the one sent by Node(X) to Node(Y). Both are triggered by the FDI indication received on their egress interface that generates the above- mentioned (downstream) sequence of ChannelStatus message. Here, by receiving from Node(X) the ChannelStatus message, Node(Y) correlates this information with the one detected at its egress interface (flowing in the upstream direction). Since, a defect indication has been received on one of its egress interfaces for the corresponding trail but not one of its ingress interfaces. Thus, Node(Y) has to rely on the ChannelStatus message sent to Node(Z) in order to know where the fault is localized. In any case, Node(Y) sends a ChannelStatus message to Node(X) indicating that the corresponding ingress interface (toward Node(X)) has not received any failure indication for that trail. This means that the failure is localized downstream to Node(Y). Therefore, neither Node(X) or Node(Y) will perform any subsequent recovery actions for that trail as the failure is located downstream and outside to the legacy SONET/SDH network. D.Papadimitriou et al. Expires May 2003 10 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 6. Link Verification and Link Property Correlation In LMP, the canonical Link Verification procedure assumes that any link verification operation is performed before inserting the user traffic. In the context, Link Verification procedure is used to deliver 1) Interface ID Mapping and Label Association at bootstrap 2) Capability to verify the connectivity of a trail when not transporting normal traffic In the current context (for instance, scenario 1), Link Connectivity Verification procedure throughout the SONET/SDH sub-network can be provided by using inherent (Path) Trail Trace mechanisms, as defined in [LMP-SONET-SDH]. This has to be performed on unallocated data links since one can not apply Path Trail Trace capabilities of the POH (J1, J2 bytes) unless the signal label (C2 byte of the POH) is supervisory unequipped together with UNEQ alarm de-activation. Thus one expects to perform this operation during the initial discovery phase. Note: using Supervisory Trail Termination (STT) function is applicable when the transport plane is not carrying user traffic. In this case the function generates a valid signal (at Node(X)) that can be supervised from the other side (at Node(Y), for instance). Moreover, one has to consider that [LMP] does not allow the exchange of the SONET/SDH label in order to provide a consistent interface ID/Label association between non-adjacent deviceÆs interfaces. Thus in addition to exchange of the interface ID during Link Verification (see [LMP-SONET-SDH]) one foresees here the exchange of the corresponding Label value (see [GMPLS-SONET-SDH]). The corresponding message exchange only involves (as described in [LMP]) local interface identifier exchange in such a way that provisioning of the non-adjacent device corresponding values are dynamically discovered. Once this interface mapping and label association is available at the nodes bordering the legacy SONET/SDH network (for instance, Node(X) and Node(Y)), trail bundling operation can be performed. Trail bundling extends the Link Property Correlation from the section to the path level allowing the grouping of path trails having for instance, the same Resource Class and Traffic Engineering Metric as specified in [GMPLS-ARCH]. However, one of the major aspects is to define a (path) trail correlation property enabling to group most (if not any) of the SONET/SDH specific path attributes such as performance monitoring capabilities and (configurable) thresholds for instance. 6.1 Discovery LMP delivers transport (or data) plane independent mechanisms while still allowing for specific usage of the data plane barrier technology. In particular, when considering SDH or OTH data planes, D.Papadimitriou et al. Expires May 2003 11 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 the transport of the Test and Bootstrap messages can be considered and combined with the LMP (control plane) capabilities. In turn, this enables the elaboration of discovery functions. 6.1.1 (Signalling) Transport Mechanisms Two classes of signalling transport mechanisms are defined. The first class is defined as embedded in the data plane channels (in- band) and second one is dissociated from the data plane channels (out-of-band). Depending on the transmission medium one gets the following classes: in-band (thus in-fiber) signalling transport mechanism using [RFC-1662] framing and out-of-band signalling transport mechanism using [RFC-2615]. On the other hand, several transport mechanisms can be considered for the Test [LMP-SONET-SDH-TEST] and the Bootstrap [LMP-BOOT] message exchange (in-band, by definition): For Sonet/SDH data planes: - Section/RS Trace (J0) - STS SPE/HOVC and VT SPE/LOVC Path Trace (J1/J2) - Section/RS Data Communication Channel DCC(1-3) overhead bytes - Line/MS DCC(4-12) overhead bytes For OTH data planes: - OTUk Trail Trace Identifier (TTI) - ODUk Trail Trace Identifier (TTI) - OTUk General Communication Channel GCC(0) overhead bytes - ODUk GCC(1/2) overhead bytes 6.1.2 Independence between Data and Control Plane LMP Control channels exist independently of both data links and TE links and multiple control channels may be active simultaneously between a pair of nodes. Between these nodes, individual control channels can be realized in different ways as explained here above. Their configuration parameters must be negotiated over each individual control channel, and LMP Hello packets must be exchanged over each control channel to maintain LMP connectivity if other mechanisms are not available. Moreover since one assumes that the control channels are terminated in the digital domain at each node, it is also possible to detect control channel failures using data plane (e.g., SONET/SDH or OTH) detection mechanisms. However, this method introduces a self- consistence problem when using in-fiber in-band signalling transport mechanism and should only be used in combination with LMP Hellos to detect neighboring node failure. 6.1.3 (Auto-)Discovery Discovery of the neighboring nodesÆ interfaces consists in finding the mapping between local interface_id and the remote interface_id. D.Papadimitriou et al. Expires May 2003 12 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 Thus, this is simply referred to as data link discovery. On the other hand, auto-discovery provides additionally the dynamic setup of the control channel through which this information will be exchanged (thus at the control plane level). Therefore, auto- discovery joins discovery of the data plane interface_id (and their correlation) with the automated establishment of the control channels (also referred to as control channel bootstrapping). On the contrary discovery implies the a-priori (static) configuration of the control channels between the neighboring nodes. 1. Discovery Discovery (of the data links) implies the previous setup of (at least one) bi-directional control channel with the neighboring node with which the link verification procedure will be initiated. The link verification procedure thanks to its negotiation phase of the transport mechanism to be used for the exchange of Test messages (see [LMP-SONET-SDH-TEST]) allows for interface_id mapping discovery (i.e. common knowledge of the data link identifier pair). These data link identifiers will be subsequently correlated using the (data) link property correlation function of LMP. The BeginVerify message exchange includes also the capability to associate the interfaces to be discovered to the TE link_id. The latter will be used when the data link properties will be correlated using the LinkSummary message exchange. The importance of discovery in managing links is noticeable among others in the following cases: - during the setup/initial configuration phase: avoid the manual provisioning and configuration of all this information on every node (a N node network with an average connectivity degree D, results in D x N operations) - during modification of the link topology all actions can be performed dynamically without starting to worry about mis- configurations, manual tables, etc. 2. Auto-Discovery Auto-discovery can be defined as the combination of an automated (bi-directional) control channel setup and the discovery of the data plane interface_id mappings between neighboring nodes (for their sub-sequent correlation). This mechanism differs from discovery in that it doesnÆt consider previous negotiation through the control plane between neighboring nodes before initiating the link verification procedure. Using LMP, auto-discovery relies thus on control channel bootstrapping which is defined as the procedure of automatically discovering the neighboring node (i.e., learning the address of the node) and the IP address(es) of the neighborÆs control channel end-points. In these conditions, the Test message (used during the link connectivity verification procedure) is replaced by a Bootstrap message (see [LMP-BOOT]) that allows the receiving node to setup the D.Papadimitriou et al. Expires May 2003 13 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 (bi-directional) control channel with the sender of the Bootstrap message. This control channel is then used to the send the interface_id mapping to the Bootstrap message sender. 3. Flowcharts The following flowcharts summarize the LMP function usage for discovery and auto-discovery: Auto-Discovery Discovery ------------- Existing CC | Bootstrap | In-band Bootstrap LMP Adjacency Up ------------- message . | . | . ------------- ------------------- | CC Setup | LMP Adjacency In-band Test | Link Verification | ------------- setup message ------------------- | | ---------------------- Data Link(s) discovered --------------------- | | ------------- ------------- | Data Link | LinkSummary LinkSummary | Data Link | | Correlation | message message | Correlation | ------------- ------------- | | ------------------------- TE Link discovered ----------------------- | | | | ==================================================================== | | | | ----------------> IGP-TE (OSPF/ISIS) <--------- 6.2 Multi-region and TE links A GMPLS-capable node may (under its local control policy configuration) advertise an LSP as a TE link into the same ISIS/OSPF instance as the one that determines the path taken for this LSP. Such a link is referred to as a Forwarding Adjacency (FA) and the corresponding LSP to as a forwarding adjacency LSP or simply FA-LSP (see [MPLS-HIER]). Since the advertised entity appears as a link in OSPF, both end-point nodes of the FA-LSP must belong to the same OSPF area (intra-area improvement of scalability). Afterwards, OSPF floods the link-state information about FAs just as it floods the information about any other TE link allowing other nodes to use FAs as any other TE links for path computation purposes. The use of FAÆs provides a mechanism for improving bandwidth utilization when its dynamic allocation can be performed in discrete units; it also enables aggregating forwarding state, and in turn, reducing significantly the number of required labels. Therefore, the usage of FAs can significantly improve the scalability of GMPLS TE-capable D.Papadimitriou et al. Expires May 2003 14 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 control planes, and allow the creation of a (nested) TE LSP hierarchy. Notice that Forwarding Adjacencies can also be unnumbered and thus treated as an unnumbered TE link or an unnumbered component link of a bundled link. In this context, LMP capabilities can be extended to enable FA-LSP initiation, verification and bundling. The usefulness of the proposed mechanism is illustrated by the following multiple LSP regions case description: -- Node(X) <-------------------- LMP -------------------> Node(Y)--- . | | . . | | . . | | . . Node(X) <--LMP--> Node(1)<-..LMP..-->Node(N) <--LMP--> Node(Y) . . . . . . . . . . .<----------LSP Region n+1---------->. . . . .<------------------------- LSP Region n ------------------------->. Typically, Node(1) to Node(N) belongs to one LSP region (for instance, Lambda Switching Capable) and the LSPs established through these nodes crosses the LSP region boundary at Node(X) and Node(Y) that belongs for instance to the TDM region or Lambda Switching Capable (LSC) region (see [draft-ietf-mpls-lsp-hierarchy-07.txt]). When dealing with non-PSC regions, LSPs and TE links are defined as the control plane mapping of the transport plane path and section entities (a.k.a. trails), respectively. Therefore, the LSP established through region (n+1) appears as a TE link at LSP Region (n) and are referred to as a Forwarding Adjacency LSP (FA-LSP). In this context, the main issues are on one hand related to the TE link assignment performed at the boundary between region (n+1) and Region n while only its sub-components may be the object of an FA- LSP setup. Moreover, when an FA is dynamically triggered, the TE attributes of its FA-LSP are inherited from the LSP which induced its creation. Therefore, once setup these FA-LSPs appear at the region n as TE links with the interface switching capability that have raised the corresponding LSPs at region n+1. For instance, the triggering of an FA-LSP with TDM switching capability is only possible if both Node(X) and Node(Y) through the TE links they define with their neighboring nodes (i.e. Node(1) and Node(N)) give access to a lower level region switching capability region such as LSC or FSC. On the other hand, the correlation of FAÆs having similar Traffic Engineering (TE) attributes can induce the creation of an FA bundle (here, in this example between Node(X) and Node(Y)). The number of FAÆs that may be included in this bundle is at most as large as the number of components of the TE links defined between Node(X) and D.Papadimitriou et al. Expires May 2003 15 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 Node(1) and between Node(N) and Node(Y). In addition, verification of the FA-LSPs is also possible just as data links by simply using the link verification capabilities of LMP. Note also there is a similarity between this and the context where [LMP-WDM] protocol is defined: Node(X) and Node(Y) corresponds to OXC and Node(1) to Node(N) to Optical Line System (OLS); the only exception is that in the latter case, one of the LMP neighbor is a non GMPLS-capable node. 7. LMP-WDM Applicability In this section, we address the applicability (and the potential extension) of the LMP(-WDM) capabilities to support information exchange between SONET/SDH nodes connected via a non-SONET/SDH sub- network, for instance a legacy Optical Transport Hierarchy (OTH) sub-network. In this context, the main difference with respect to the LMP-WDM scope is that the switching capable element is not necessarily GMPLS-capable. Therefore, in this case, the server entity may support one or more switching capability and not only optical channel multiplexing capability, as it is the case with Optical Line Systems (see [CCAMP-OLI]). As described in [LMP-WDM], LMP for WDM systems helps in maintenance of control channel connectivity, verification of component link connectivity, and link, fiber, or channel failures within the network between Cross-Connects and Optical Line Systems (OLS). These extensions to LMP are referred to as LMP-WDM and have been designed in compliance with the ôcarrier requirementö specification (see [OLI]). However, this protocol can be easily extended to cover additional technologies extending beyond ôpre-OTNö such as OTH and SONET/SDH. Thus, the three LMP/LMP-WDM scenarios can also be considered for these environments. 7.1 Scope and Scenarios Here, using the generic (inter-connection) scenario 2, where the SONET/SDH nodes (LMP Network edge nodes) maintain trails through a non-SONET/SDH network, one gets the following reference architecture: LMP Network <-- --- LMP-WDM Sub-Network --- --> LMP Network | | | | | | SONET/SDH Net <-- --> non-SONET/SDH Sub-Net <-- --> SONET/SDH Net Edge Node(X) Node(1) ---- Node(N) Edge Node(Y) | | | | | | | ---LMP-WDM--- ---LMP-WDM--- | | | <-----------------------LMP-------------------------> D.Papadimitriou et al. Expires May 2003 16 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 The usefulness of the proposed mechanism is illustrated by the following case description: SONET/SDH Node(X) <------------LMP-----------> SONET/SDH Node(Y) ^ ^ | | |LMP-WDM LMP-WDM| | | v v Node(1) <------- Node(2) <-- Subnet --> Node(i) -------> Node(N) \ / -------------------------- OTN -------------------------- Note that in order to achieve consistency one should ensure that Node(1) and Node(N) are necessarily synchronized concerning the information they exchange with both edge Node(X) and Node(Y). Here, the analogy with LMP-WDM (defined between OLS and PXC/OXC) can be drawn as follows: Node(X) and Node(Y) corresponds to PXC/OXC and Node(1) to Node(N) to Optical Line System (OLS); the only exception is that the LMP capable nodes (i.e. Node(X) and Node(Y)) are not necessarily GMPLS-capable nodes. As such, LMP-WDM provides the mechanism enabling cross technology information exchange while LMP provides the peer information exchange. In this model, one assumes that the OTN border nodes are LMP-WDM capable only, while Node(X) and Node(Y) are GMPLS capable (and in particular LMP capable). Using this LMP-WDM, Node(X) can set Performance Monitoring parameters (for instance BER thresholds) to Node(1) (the same occurs at the other side between Node(Y) and Node(N)); the border nodes Node(1) and Node(N) can report alarm (after correlation or not) to the SONET/SDH nodes. One gets also the capability to perform trail tracing between Node(1) and Node(N) without having to modify the hardware capabilities of any of the involved devices. Moreover, the LMP Session between the Node(X) and Node(Y) can be used to provide label association (and subsequently explicit label control if GMPLS is supported by the edge sub-networks). Note that the above Control Channel topology and LMP adjacencies can be modified in order to achieve nested LMP and LMP-WDM sessions: LMP Network <-- --- LMP(-WDM)Sub-Network --- --> LMP Network | | | | SONET/SDH Net <-- --> non-SONET/SDH Sub-Net <-- --> SONET/SDH Net Edge Node(X) Node(1) --- Node(N) Edge Node(Y) | | | | | | D.Papadimitriou et al. Expires May 2003 17 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 | | | | | | --LMP-WDM-- === -- LMP -- === --LMP-WDM-- This case is particularly interesting because SONET/SDH Network edge nodes are only LMP-WDM capable. Using the corresponding sessions would enable to bridge through the LMP session defined between Node(1) and Node(N), information such as the one that would be exchanged using a direct IP Control Channel between edge nodes (i.e. Node(X) and Node(Y)). This would be then equivalent to the architecture described here above where one additional and dedicated LMP session is defined between Node(X) and Node(Y). Here the LMP session between Node(1) and Node(N) (or its hop by hop equivalent) should be fast enough in order to avoid any mismatch of information exchanged when using the LMP-WDM and the LMP session. This scheme also enables a faster correlation of defect indications and notifications (such as the one exchanged through ChannelStatus message). The LMP-WDM session between Node(X) and Node(1) (and between Node(N) and Node(Y)) enables for the former to determine whether or not the failure (a LoS or a LoL for instance, and this depending on the transport plane interface capabilities) is due to an internal sub-network failure or is localized outside this sub- network. 7.2 Control Channel Depending on the overhead termination of the edge SONET/SDH nodes either a Section/RS DCC or a Line/MS DCC in-band Control Channel implementation can be considered. 7.3 Link (Section) Verification Here, we can apply RS/Section trail tracing capabilities using J0 byte of the RS/Section OH for contiguous Link Verification coupled with an out-of-band Test message exchange, as defined in [LMP-SONET- SDH-TEST]. When using RS/Section trail tracing in combination with an out-of-band Test message, the J0 Trace pattern mapping is performed between section termination points (i.e. between OXC1- OLS1, OLS1-OLS2 and OLS2-OXC2). ------ ------ ------ ------ | | ----- | | | | ----- | | | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 | | | ----- | | | | ----- | | ------ ------ ------ ------ ^ ^ ^ ^ ^ ^ | | | | | | | ---LMP-WDM--- ---LMP-WDM--- | | | ----------------------LMP----------------------- D.Papadimitriou et al. Expires May 2003 18 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 In the above figure, the Test procedure used with OLSs is the same as described in [LMP]. The negotiation of the Transport Mechanism (included in the BeginVerify and BeginVerifyAck messages) is used to allow nodes to negotiate a Link Verification method and is essential for OLSs that have access to overhead bytes rather than the payload. The VerifyId (provided by the remote node in the BeginVerifyAck message, and used in all subsequent Test messages) is used to differentiate Test messages from different LMP Link Verification procedures. In addition to the Test procedure described in [LMP], the trace monitoring function of [LMP-SONET-SDH-TEST] may be used for Link Verification when the OLS ports are SONET or SDH capable as it is the case in the present context. In a combined LMP and LMP-WDM context, for example, the OXC1-OLS1 LMP session manages the data links between OXC1 and OLS1, and the OXC2-OLS2 LMP session manages the data links between OXC2 and OLS2. However, the OXC1-OXC2 LMP session manages the data links between OXC1 and OXC2, which are actually a concatenation of the data links between OXC1 and OLS1, the DWDM span between OLS1 and OLS2, and the data links between OXC2 and OLS2. Note that it is these concatenated links which comprise the TE links which are advertised in the GMPLS TE link state database. The implication of this is that when the data links between OXC1 and OXC2 are being verified, using the LMP link verification procedure, OLS1 and OLS2 need to make themselves transparent with respect to these concatenated data links. The co- ordination of verification of OXC1-OLS1 and OXC2-OLS2 data links to ensure this transparency is the responsibility of the nodes, OXC1 and OXC2. The complete verification procedure is defined as follows: A BeginVerify message is sent from OXC1 to OLS1 with the following Verify Transport Mechanism: transparent upon reception of this message the OLS will send the corresponding data links in a pass- through mode. The same operation is expected to occur at the other end upon reception of the BeginVerify message sent from OXC1 to OXC2. Thus one sees the following sequence of operations: BeginVerify OXC1->OLS1 If BeginVerifyNack OLS1->OXC1 then Stop Otherwise (if BeginVerifyAck OLS1->OXC1) then continue BeginVerify OXC1->OXC2 If BeginVerifyNack OXC2->OXC1 then Stop Otherwise (if BeginVerifyAck OLS1->OXC1) then continue BeginVerify OXC2->OLS2 D.Papadimitriou et al. Expires May 2003 19 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 If BeginVerifyNAck OLS2->OXC2 then BeginVerifyNack OXC2->OXC1 If BeginVerifyAck OLS2->OXC2 then BeginVerifyAck OXC2->OXC1 Once each of entities involved in the procedure have been synchronized the Link Verification of the data link concatenation may be performed. 7.4 Link (Section) Property Correlation TBD 8. Conclusion By adding the discussed extensions to LMP and LMP-WDM a seamless bridging of legacy network parts between GMPLS enabled nodes can be achieved. This will ease the introduction of GMPLS in todayÆs networks. This way, legacy parts of the network can be bridged without impacting procedures and mechanisms in the GMPLS Network. 9. Security Considerations This document does not introduce additional security considerations as the one already covered in [LMP]. 10. References [GMPLS-ARCH] E.Mannie (Editor) et al., æGeneralized Multi-Protocol Label Switching (GMPLS) ArchitectureÆ, Internet Draft, Work in progress, draft-ietf-ccamp-gmpls-architecture- 03.txt. [GMPLS-LDP] L.Berger (Editor) et al., æGeneralized MPLS Signaling -CR-LDP ExtensionsÆ, Internet Draft, Work in progress, draft-ietf-mpls-generalized-cr-ldp-07.txt. [GMPLS-RSVP] L.Berger (Editor) et al., æGeneralized MPLS Signaling - RSVP-TE ExtensionsÆ, Internet Draft, Work in progress, draft-ietf-mpls-generalized-rsvp-te-09.txt. [GMPLS-SIG] L.Berger (Editor) et al., æGeneralized MPLS - Signaling Functional DescriptionÆ, Internet Draft, Work in progress, draft-ietf-mpls-generalized-signaling-09.txt. [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al., æGeneralized MPLS û SDH/Sonet SpecificsÆ, Internet Draft, Work in progress, draft-ietf-ccamp-gmpls-sonet- sdh-07.txt, October 2002. [LMP] J.P.Lang (Editor) et al., ôLink Management Protocol,ö Internet Draft, Work in progress, draft-ietf-ccamp- lmp-06.txt. D.Papadimitriou et al. Expires May 2003 20 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 [LMP-SONET-SDH] S.Ansorge et al., ôLMP Extensions for Sonet and SDHö, Internet Draft, Work in progress, draft-ansorge- ccamp-lmp-sonet-sdh-01.txt. [LMP-SONET-SDH-TEST] J.Lang, D.Papadimitriou et al. ôSonet/SDH Encoding for Link Management Protocol (LMP) Test Messagesö, Internet Draft, Work in progress, draft- ietf-ccamp-lmp-sonet-sdh-00.txt. [LMP-BOOT] J.Lang, D.Papadimitriou et al. ôControl Channel Bootstrap for Link Management Protocolö, Work in progress, draft-lang-ccamp-lmp-bootstrap-01.txt. [LMP-WDM] A.Fredette and J.P.Lang , (Editors), ôLink Management Protocol (LMP) for DWDM Optical Line Systems,ö Internet Draft, Work in progress, draft-ietf-ccamp-lmp-wdm- 01.txt. [MPLS-BUND] K.Kompella et al., ôLink Bundling in MPLS Traffic Engineeringö, Internet Draft, Work in progress, draft- ietf-mpls-bundle-04.txt. [MPLS-HIER] K.Kompella et Y.Rekhter, ôLSP Hierarchy with Generalized MPLS TEö, Internet Draft, Work in progress, draft-ietf-mpls-lsp-hierarchy-08.txt. [RFC2026] S.Bradner, "The Internet Standards Process -- Revision 3", RFC 2119, October 1996. [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. 11. Author's Addresses Gert Grammel (Alcatel) Lorenzstrasse 10 70435, Stuttgart, Germany Phone: +49 711 821-35863 Email: gert.grammel@alcatel.de Dimitri Papadimitriou (Alcatel) Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: dimitri.papadimitriou@alcatel.be Stefan Ansorge (Alcatel) Lorenzstrasse 10 70435, Stuttgart, Germany Phone: +49 711 821-33744 Email: stefan.ansorge@ks.sel.alcatel.de D.Papadimitriou et al. Expires May 2003 21 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 Wojciech Bigos (AGH University of Technology) Department of Telecommunications Al. Mickiewicza 30, 30-059 Krakow, Poland Phone: +48 12 617-3967 Email: bigos@kt.agh.edu.pl F.-Joachim Westphal (T-Systems Nova) Technologiezentrum Goslarer Ufer 35, D-10589 Berlin, Germany Phone: +49 30 3497-4380 Email: fritz-joachim.westphal@t-systems.com Frank Tetzlaff (T-Systems Nova) Technologiezentrum Goslarer Ufer 35, D-10589 Berlin, Germany Phone: +49 30 3497-4448 Email: frank.tetzlaff@t-systems.com Appendix I. SDH Supervision Capabilities Reference: ITU-T G.806 1. Continuity supervision Continuity supervision monitors the integrity of the continuity of a channel. This operation 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 path layer networks a replacement signal might be generated by an open connection matrix (e.g. Unequipped signal for SDH). The detection of this replacement signal is then an indication of loss of continuity. 1.1 Loss Of Signal (LoS) LOS signal supervision is used at the physical layer. Detection of "incoming signal absent" occurs the incoming power level at the receiver has dropped to a level corresponding to a high error condition. 1.2 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 Unequipped is only defined for paths and not for RS/Section or MS/Line trails. D.Papadimitriou et al. Expires May 2003 22 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 1.3 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 state. The LTC shall be cleared if the multiframe alignment process is in the In- Multiframe state. Note that Unequipped defect is only defined for paths and not for RS/Section or MS/Line trails. 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. 2.1 Trail Trace Identifier Processing and Trace Identifier Mismatch TBD. 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. 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). LOA is the generic defect term referring to loss of frame (LOF), loss of multiframe (LOM) or loss of pointer (LOP). 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. 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)), D.Papadimitriou et al. Expires May 2003 23 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 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. 3. Signal quality supervision Signal quality supervision in general monitors the performance of a trail. If the performance crosses a certain threshold this might activate a defect. 3.1 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. (n consecutive seconds with at least M block failures per second). 4. Alignment supervision Alignment supervision checks that 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. The defect detection process shall be normally tolerant to single frame slips, but should detect for continuous frame slips. 5. Maintenance signal supervision D.Papadimitriou et al. Expires May 2003 24 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 Maintenance signal supervision is concerned with the detection of maintenance indications in the signal. 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. D.Papadimitriou et al. Expires May 2003 25 draft-papadimitriou-ccamp-lmp-ls-applicability-01.txt Nov. 2002 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." D.Papadimitriou et al. Expires May 2003 26