CCAMP Working Group S. Ansorge (Alcatel) Internet Draft W. Bigos (AGH) Category: Informational G. Grammel (Alcatel) Expiration Date: December 2002 D. Papadimitriou (Alcatel) F. Tetzlaff (T-Systems) F.-J. Westphal (T-systems) June 2002 Applicability of LMP (and LMP-WDM) to Link Segments draft-papadimitriou-ccamp-lmp-ls-applicability-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. 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. 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]. D.Papadimitriou et al. Expires December 2002 1 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 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 does 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 exists the recent proposed LMP protocol and appropriate enhancements like LMP- SDH [LMP-SONET-SDH]. The missing link is the communication between and across both sub-networks. This document proposes LMP and LMP-WDM as lightweight protocols to essentially communicate 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 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. 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], 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. D.Papadimitriou et al. Expires December 2002 2 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 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 5 and 6), 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 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: 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) | | | | | | D.Papadimitriou et al. Expires December 2002 3 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 <---------------------- 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 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 | | D.Papadimitriou et al. Expires December 2002 4 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 | | | | 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 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). D.Papadimitriou et al. Expires December 2002 5 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 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-SDHSONET] 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) 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) | D.Papadimitriou et al. Expires December 2002 6 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 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: 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 D.Papadimitriou et al. Expires December 2002 7 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 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 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. D.Papadimitriou et al. Expires December 2002 8 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 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) 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 D.Papadimitriou et al. Expires December 2002 9 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 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. 6. Link Verification and 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 D.Papadimitriou et al. Expires December 2002 10 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 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. 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 D.Papadimitriou et al. Expires December 2002 11 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 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-------------------------> 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. D.Papadimitriou et al. Expires December 2002 12 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 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) | | | | | | | | | | | | --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 D.Papadimitriou et al. Expires December 2002 13 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 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]. 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. at Node(X) and Node(Y)). 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. 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- 02.txt, February 2002. [GMPLS-LDP] L.Berger (Editor) et al., æGeneralized MPLS Signaling -CR-LDP ExtensionsÆ, Internet Draft, Work in progress, draft-ietf-mpls-generalized-cr-ldp-06.txt, April 2002. [GMPLS-RSVP] L.Berger (Editor) et al., æGeneralized MPLS Signaling - RSVP-TE ExtensionsÆ, Internet Draft, Work in progress, draft-ietf-mpls-generalized-rsvp-te-07.txt, April 2002. [GMPLS-SIG] L.Berger (Editor) et al., æGeneralized MPLS - Signaling Functional DescriptionÆ, Internet Draft, Work in progress, draft-ietf-mpls-generalized-signaling-08.txt, April 2002. [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al., æGeneralized MPLS û SDH/Sonet SpecificsÆ, Internet D.Papadimitriou et al. Expires December 2002 14 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 Draft, Work in progress, draft-ietf-ccamp-gmpls-sonet- sdh-05.txt, May 2002. [LMP] J.P.Lang (Editor) et al., ôLink Management Protocol,ö Internet Draft (work in progress), draft-ietf-ccamp- lmp-03.txt, March 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, February 2002. [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- 00.txt, February 2002. [MPLS-BUND] K.Kompella et al., ôLink Bundling in MPLS Traffic Engineeringö, Internet Draft (work in progress), draft- ietf-mpls-bundle-03.txt, May 2002. [MPLS-HIER] K.Kompella et Y.Rekhter, ôLSP Hierarchy with Generalized MPLS TEö, Internet Draft (work in progress), draft-ietf-mpls-lsp-hierarchy-05.txt, May 2002. [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) Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-4453 Email: gert.grammel@netit.alcatel.it 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 7 11 821-33744 Email: stefan.ansorge@ks.sel.alcatel.de Wojciech Bigos (AGH University of Technology) Department of Telecommunications D.Papadimitriou et al. Expires December 2002 15 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 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 Address: 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 Address: 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. 1.3 TC Loss of Tandem Connection (LTC) D.Papadimitriou et al. Expires December 2002 16 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 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 TTI 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)), a LOM defect shall be declared. Once in a LOM state, this state shall be exited when the multiframe is recovered. D.Papadimitriou et al. Expires December 2002 17 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 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 Maintenance signal supervision is concerned with the detection of maintenance indications in the signal. D.Papadimitriou et al. Expires December 2002 18 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 2002 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 December 2002 19 draft-papadimitriou-ccamp-lmp-ls-applicability-00.txt June 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 December 2002 20