The MPLS-OPS Archive
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index][Thread Index][Author Index][Subject Index]
Re: IMA E1 card and MPLS
-
From: "Shravan N" <shravan.nagraj@gmail.com>
-
Date: Sun, 12 Nov 2006 23:20:33 +0530
-
Cc: Alaerte.Vidali@nokia.com, mpls-ops@mplsrc.com
-
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=NsVB4R03ff5wFo4rnYsQuLuVJIhHbaoUA3W3Iuwtu01TBvNpBOTS/vx2bft2yTysXNG2ZEHXzNsU+H12hbwbXrU2+HYNBP89+eOhKABRFurTj6HFT1LlFtHFllP/VTs6R/fVwVk4/9Y1FHS9knIVMpwagpDv5Jy18MB1JWYA6xE=
-
Resent-Date: Sun, 12 Nov 2006 13:32:36 -0500
-
X-Scanned-By: MIMEDefang 2.53 on 209.239.41.31
-
X-Security: MIME headers sanitized on host.secure4-hosting.netSee http://www.impsec.org/email-tools/sanitizer-intro.htmlfor details. $Revision: 1.138 $Date: 2003-01-26 11:25:54-08
-
X-SpamProbe: GOOD 0.0000000 6fc86b38131b82e4a289cd9bdf53c4e2
Thanks to Rajesh for Details on IMA.
From my experience, I know that E1s over multilinks can have lot of issues while using mlppp. The root cause is the low resiliece of the E1 Links. some times they may even flap during peak or bursty traffic. Juniper in their latest releases showed good functionality during the flapping of E1s on multilink. There were complaints from users at the sites still however the multilink stayed up.
Even if you are upgrading your solution, it is a good idea to test your problematic areas on the new setup before deploying.
On 11/6/06, rajesh.parikh@wipro.com <rajesh.parikh@wipro.com> wrote:
Hi,
A good IMA solution compliant to the specification should take care of the condition you mentioned. It should not matter at the MPLS layer
To explain in few words...
IMA protocol synchronizes on the ICP cells (OAM) for synchronization of frames and it implements something known as IFSM (IMA frame synchronisation state machine) to take care of TC/physical link anomalies. It also integrates any phy layer faults/defects and has clearly defined primitives for initiating Far End Reporting. For the condition mentioned by you, A link failure on one of the links should not cause link failures/flaps on other links part of the same IMA Group.
A flap on the link once detected causes discard of cells during the anomaly period, until either the link recovers or is declared to be in LIF state (Loss of IMA frame). This triggers link to be declared as faulty by the IMA receiver who initiates Far End Reporting and brings down the link from the IMA group (aggregator).
Hope that helps.
Cheers,
Rajesh
Hi,
Have you used MPLS over IMA?
We have a network with E1 multilink but when there is a flapping on one link, the all multilink suffers. We did a test bed to verify if Interface Damping could help, but it does not work fine when the interface belongs to Multilink.
Now we are considering scalable ATM IMA solution, using multiple E1 connections instead of OC-3 (I would prefer OC-3 but it is not an option)
Did you know the behavior of IMA card when there is a flapping on one of the E1 links?
Thanks,
Alaerte
| |
|