RE: [T1X1.5] Re: Suppression of Downstream Alarms...
"George Young" <george.young@meriton.com> Wed, 21 November 2001 16:15 UTC
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 21 Nov 2001 08:18:46 -0800
content-class: urn:content-classes:message
Subject: RE: [T1X1.5] Re: Suppression of Downstream Alarms...
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C172A7.ACBA2C53"
Date: Wed, 21 Nov 2001 11:15:02 -0500
Message-ID: <E5A6D1B50FEDDF4ABE699DE2ECF57A8103DCA7@edgsvr04.edgeflow.edgeflow.com>
Thread-Topic: RE: [T1X1.5] Re: Suppression of Downstream Alarms...
Thread-Index: AcFyp6yhQ3WgSQEYQkWPvZogP+25sw==
From: George Young <george.young@meriton.com>
To: ccamp@ops.ietf.org
A couple of my mail message on this subject were bounced whilst I was in the process of changing email address to correspond with my company's new name. 2 Attachments: <<RE: [T1X1.5] Re: Suppression of Downstream Alarms...>> <<RE: [T1X1.5] Re: Suppression of Downstream Alarms...>>
--- Begin Message ---Hello Carmine, For span protection, LMP can stand on its own, localizing the fault, making sure that both ends of the fault span know about the failure. In a transparent network (which is where my company is focused), the node at the receive end of a faulty link, and any nodes downstream (in the data flow direction) become aware of the fault, so one end of the path knows almost immediately. For path protection, there would still be a need for signalling to the other end. The benefit of using LMP to localize the fault, is that only one node need initiate the signalling to the head and the tail of the connection to toggle to the backup path. Regards, George R. Young Meriton Networks Inc. 329 March Rd., Kanata, ON, Canada, K2K 2E1 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9268 -----Original Message----- From: Carmine Daloia [mailto:daloia@lucent.com] Sent: Wednesday, November 21, 2001 9:23 AM To: George Young Cc: ccamp@ops.ietf.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Hi George, Thanks for the pointer to your draft. I will definitely read over it. Just looking at it quickly and understanding what is in LMP, it seems that even under path protection/restoration, there is an intermediate node that detects a failure (and localizes the failure to ensure that the failure occured on that particular link) and then signals over the control plane to the head-end and tail-end nodes of the protection/restoration domain to initiate protection/restoration. It seems to me that the tail-end and head-end nodes themselves would be able to detect the defect in the transport/user plane since the defect occured between the two ends and they can then coordinate switching for protection/restoration without having to wait for any notification message sent from an intermediate NE. This should improve the protection/restoration time since the head-end and tail-end won't need to wait for intermediate nodes to localize a fault and then signal over a control plane requesting a proteciton/restoration switch. Any thoughts? Thanks Carmine George Young wrote: Hello Carmine, Meriton Networks intends to use LMP as a fault localization mechanism in a network of our transparent optical switches, currently in the pre-production phase. I've done some discrete event simulation work to characterize the performance of an IP network in support LMP management signals, and the resulting signalling messages needed to initiate protection/restoration, and based on the results, have not seen any need to change our design direction. I've also written and submitted an IETF draft http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-0 0.txt dealing with the importance of control network performance, particularly when extended across multiple networks, and would appreciate any comments you might have. Regards, George R. Young Meriton Networks Inc. 329 March Rd., Kanata, ON, Canada, K2K 2E1 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9268 -----Original Message----- From: Carmine Daloia [ mailto:daloia@lucent.com] Sent: Wednesday, November 21, 2001 8:29 AM To: Carmine Daloia Cc: Jonathan Lang; ccamp@ops.ietf.org; tsg15q11@itu.int; t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Jonathan, Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM. Thanks Carmine Carmine Daloia wrote: Jonathan, The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP. Let's look at the following network. OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers. Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc... Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP. Thanks Carmine Jonathan Lang wrote: Carmine, Please see inline. Thanks, Jonathan -----Original Message----- From: Carmine Daloia [ mailto:daloia@lucent.com] Sent: Monday, November 19, 2001 6:44 AM To: ccamp@ops.ietf.org Cc: tsg15q11@itu.int; t1x15@t1.org Subject: LMP: Suppression of Downstream Alarms... Hi all, As I read through Section 6 "Fault Management", one issue that it seems to be addressing is "Suppression of Downstream Alarms". In section 6.2, it states that "If data links fail between two PXCs, the power monitoring system in all of the downstream nodes may detect LOL and indicate a failure. To avoid multiple alarms stemming from the same failure, LMP provides a failure notification through the Cha nn elStatus message...". I agree that the suppression of downstream alarms is an important issue. great! If we look at standard networks (both SONET/SDH and OTN), this capability is already provided by the overhead in SDH/SONET and G.709 OTN. G.709 OTN handles suppression of alarms in both all-optical networks as well as opaque networks. I don't think we need to burden the control plane with such functions when the transport plane handles this in standard networks. In fact the transport plane handles suppression of alarms on all equipment in the network (not just cross-connects). If we look at a pre-OTN ("non-standard") scenario consisting of Cross-connects, Optical Line Systems, and Optical Amplifiers supporting a DWDM networked solution, we can analyze two scenarios. One scenario is an opaque network (e.g., the OLS supports 3R). In this scenario, the downstream Cross-connects would not detect LOL upon faults occurring upstream. The 3R points on the OLS Line Systems would insert some type of signal dow ns tream. Therefore the mechanism described in Section 6.2 does not apply. Another scenario is an all-optical pre-OTN network. Note that other equipment besides Cross-connects (e.g., Optical Amplifiers) in an all-optical network may alarm due to upstream faults. These alarms also need to be suppressed. LMP seems to only address the suppression of downstream alarms on cross-connects without taking into consideration the network that sits between the cross-connects. Is LMP also expected to have to be processed on Optical Amplifiers? This seems to be undesirable, especially given all the various applications that seem to be included into the LMP protocol that would not have anything to do with Optical Amplifieris. For interaction between cross-connects and Line Systems, please see OLI Requirements document ( http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and corresponding LMP-WDM protocol document (new version to be uploaded tomorrow, but old version can be found at http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt). Any other views? Carmine--- End Message ---
--- Begin Message ---Hello Carmine, Meriton Networks intends to use LMP as a fault localization mechanism in a network of our transparent optical switches, currently in the pre-production phase. I've done some discrete event simulation work to characterize the performance of an IP network in support LMP management signals, and the resulting signalling messages needed to initiate protection/restoration, and based on the results, have not seen any need to change our design direction. I've also written and submitted an IETF draft http://search.ietf.org/internet-drafts/draft-young-opt-nni-prot-issues-0 0.txt dealing with the importance of control network performance, particularly when extended across multiple networks, and would appreciate any comments you might have. Regards, George R. Young Meriton Networks Inc. 329 March Rd., Kanata, ON, Canada, K2K 2E1 phone: +1 613-270-9279 Ext 287 fax: +1 613-270-9268 -----Original Message----- From: Carmine Daloia [mailto:daloia@lucent.com] Sent: Wednesday, November 21, 2001 8:29 AM To: Carmine Daloia Cc: Jonathan Lang; ccamp@ops.ietf.org; tsg15q11@itu.int; t1x15@t1.org Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms... Jonathan, Forgot to mention, that the performance aspects of carrying OAM type signals over an IP based control channel in LMP-WDM would have to be analyzed. It is possible that the IP Control Channel will not provide fast enough transfer to actually suppress downstream alarms, however that needs to be analyzed as part of LMP-WDM. Thanks Carmine Carmine Daloia wrote: Jonathan, The LMP-WDM document specifies the signaling between the Cross-connect and OLS, assuming they are from different vendors. If they are from different vendors, then a standard interface is needed to exchange some information. One type of information that would need to be exchanged is some OAM signals. Maarten described some of these signals in his VBI document. However, I don't see why OAM signals would have to be exchanged directly between the cross-connects themselves via LMP. Let's look at the following network. OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4 Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical Amplifiers. Let's assume a failure on OLSA. OLSA via overhead within an OSC suppresses alarms within OLSA. OAM messages (e.g., Optical Channel FDI) could be carried over the LMP-WDM control channel to OXC2. OXC2 will have to forward the FDI signals downstream over the LMP-WDM control channel to OLSB. OLSB will then forward these FDI signals over its OSC and then over the LMP-WDM control channel to OXC3..... etc... Note that OXC2 does not need to directly forward these FDI signals to OXC3. So it is possible, that in LMP-WDM, we may need to define messages corresponding to FDI signals to suppress downstream alarms, however we don't need to define such messages in LMP. Thanks Carmine Jonathan Lang wrote: Carmine, Please see inline. Thanks, Jonathan -----Original Message----- From: Carmine Daloia [ mailto:daloia@lucent.com] Sent: Monday, November 19, 2001 6:44 AM To: ccamp@ops.ietf.org Cc: tsg15q11@itu.int; t1x15@t1.org Subject: LMP: Suppression of Downstream Alarms... Hi all, As I read through Section 6 "Fault Management", one issue that it seems to be addressing is "Suppression of Downstream Alarms". In section 6.2, it states that "If data links fail between two PXCs, the power monitoring system in all of the downstream nodes may detect LOL and indicate a failure. To avoid multiple alarms stemming from the same failure, LMP provides a failure notification through the Cha nn elStatus message...". I agree that the suppression of downstream alarms is an important issue. great! If we look at standard networks (both SONET/SDH and OTN), this capability is already provided by the overhead in SDH/SONET and G.709 OTN. G.709 OTN handles suppression of alarms in both all-optical networks as well as opaque networks. I don't think we need to burden the control plane with such functions when the transport plane handles this in standard networks. In fact the transport plane handles suppression of alarms on all equipment in the network (not just cross-connects). If we look at a pre-OTN ("non-standard") scenario consisting of Cross-connects, Optical Line Systems, and Optical Amplifiers supporting a DWDM networked solution, we can analyze two scenarios. One scenario is an opaque network (e.g., the OLS supports 3R). In this scenario, the downstream Cross-connects would not detect LOL upon faults occurring upstream. The 3R points on the OLS Line Systems would insert some type of signal dow ns tream. Therefore the mechanism described in Section 6.2 does not apply. Another scenario is an all-optical pre-OTN network. Note that other equipment besides Cross-connects (e.g., Optical Amplifiers) in an all-optical network may alarm due to upstream faults. These alarms also need to be suppressed. LMP seems to only address the suppression of downstream alarms on cross-connects without taking into consideration the network that sits between the cross-connects. Is LMP also expected to have to be processed on Optical Amplifiers? This seems to be undesirable, especially given all the various applications that seem to be included into the LMP protocol that would not have anything to do with Optical Amplifieris. For interaction between cross-connects and Line Systems, please see OLI Requirements document ( http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt) and corresponding LMP-WDM protocol document (new version to be uploaded tomorrow, but old version can be found at http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt). Any other views? Carmine--- End Message ---
- Re: FW: [T1X1.5] Re: Suppression of Downstream Al… Carmine Daloia
- FW: [T1X1.5] Re: Suppression of Downstream Alarms… Jonathan Lang
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Carmine Daloia
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Carmine Daloia
- RE: [T1X1.5] Re: Suppression of Downstream Alarms… Jonathan Lang
- RE: [T1X1.5] Re: Suppression of Downstream Alarms… Jonathan Lang
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Sudheer Dharanikota
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Carmine Daloia
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Sudheer Dharanikota
- RE: [T1X1.5] Re: Suppression of Downstream Alarms… Jonathan Lang
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Carmine Daloia
- RE: [T1X1.5] Re: Suppression of Downstream Alarms… George Young
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Dimitri Papadimitriou
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Maarten Vissers
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Sudheer Dharanikota
- Re: Suppression of Downstream Alarms... Sudheer Dharanikota
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Sudheer Dharanikota
- Re: Suppression of Downstream Alarms... Dimitri Papadimitriou
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Carmine Daloia
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Carmine Daloia
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Sudheer Dharanikota
- Re: Suppression of Downstream Alarms... Carmine Daloia
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Sudheer Dharanikota
- Re: Suppression of Downstream Alarms... Sudheer Dharanikota
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Carmine Daloia
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Carmine Daloia
- Re: Suppression of Downstream Alarms... Carmine Daloia
- Re: Suppression of Downstream Alarms... Germano Gasparini
- RE: Suppression of Downstream Alarms... neil.2.harrison
- RE: Suppression of Downstream Alarms... Jonathan Lang
- RE: Suppression of Downstream Alarms... Malcolm Betts