[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sonet Ring provisioning
- To: "Bernstein, Greg" <GregB@ciena.com>
- Subject: Re: Sonet Ring provisioning
- From: Maarten Vissers <mvissers@lucent.com>
- Date: Fri, 31 May 2002 09:59:48 +0200
- Cc: "'Nik Langrind'" <nik@equipecom.com>, "'Zhi-Wei Lin'" <zwlin@lucent.com>, "R. Muralidharan" <r.muralidharan@ossi.co.in>, "'Manoj Agiwal'" <ManojA@netbrahma.com>, "'Ccamp (E-mail)" <ccamp@ops.ietf.org>, "mpls@UU. NET (E-mail)" <mpls@UU.NET>
- Organization: Lucent Technologies
- Original-cc: "'Nik Langrind'" <nik@equipecom.com>, "'Zhi-Wei Lin'" <zwlin@lucent.com>, "R. Muralidharan" <r.muralidharan@ossi.co.in>, "'Manoj Agiwal'" <ManojA@netbrahma.com>, "'Ccamp (E-mail)" <ccamp@ops.ietf.org>, "mpls@UU. NET (E-mail)" <mpls@UU.NET>
- References: <2135200C183FD5119588009027DE57230151B13B@wntcsdexg02.csd.ciena.com>
Nik,
This issue is totally unrelated to GMPLS/ASON. The same situation is already
present for years in SDH/SONET networks (with connection management under
control of NMS). It has been analysed in great details and the conclusion was
that hold off timers provide the only solution.
Furthermore, in your example you have overall knowledge of the network
architecutre and its protection. In practice a connection often is through more
than one network operator's domain. And then you don't have overall knowledge.
I.e. the outer operator doesn't know if there is protection (and which type(s))
in the inner domain(s).
The implication of nested protection for GMPLS/ASON is that the restoration
process in GMPLS/ASON must support hold off timers as well. If an operator will
use these and what values it will give is outside the scope of GMPLS/ASON work.
Furthermore, when a protected connection is to be set up via GMPLS/ASON,
GMPLS/ASON must set up the:
- working connection,
- protection connection,
- appropriate monitoring of working connection
- appropriate monitoring of protection connection
- bridge and selector at A end
- bridge and selector at Z end
- provisioning of protection related management information as defined in the
equipment standards (e.g. G.705, G.783, G.798, I.732) and protection swithcing
recommendations (e.g. G.841, G.gps.1); this includes hold off time, wait to
restore time, etc.
Regards,
Maarten
"Bernstein, Greg" wrote:
>
> Hi Nick good points. The interaction of protection types can be tricky. The
> typical technique is to use "hold off timers" to first give a "faster"
> protection type a chance to respond. This works well when say source
> reroute mesh (at say the SONET path layer) is used to back up a connection
> that traverses say a number of rings (say BLSRs). However, in your example
> below it would also imply waiting an extra time period before kicking of the
> mesh.
>
> Greg
>
> ***********************************
> Dr. Greg M. Bernstein
> Senior Technology Director, Ciena Corporation
>
> -----Original Message-----
> From: Nik Langrind [mailto:nik@equipecom.com]
> Sent: Thursday, May 30, 2002 7:06 AM
> To: 'Zhi-Wei Lin'; R. Muralidharan
> Cc: Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET
> (E-mail)
> Subject: RE: Sonet Ring provisioning
>
> Hi,
>
> If a path that is set up via GMPLS signaling traverses a SONET ring, and the
> SONET ring is managed via an EMS as Greg suggests, how do the two protection
> domains interact? The two protection domains I am thinking of are as
> follows:
>
> 1) The Ring protection domain - failures in the ring itself are protected,
> by ring-specific mechanisms
>
> 2) The end-to-end protection domain - failures anywhere along the path are
> protected, presumably by failing over to a diversely routed path
>
> J------K
> / \
> A ------B------H------I L-------O-------Y--------Z
> \ \ / /
> \ N------M F------G
> \ /
> C---------------D---------E
>
> Endpoints A and Z have an LSP (an end-to-end SONET path) switched across the
> ring (I-J-K-L-M-N). LSRs B and Y provide a redundant LSP across the path
> C-D-E. Presumably, the nodes B and Y provide a path monitoring function,
> similar to UPSR, that they can use to initiate a switch to the protect LSP.
>
> If a failure happens in the ring, it will be recovered from, via
> line-switching or ring-switching inside the ring. But the path monitoring
> function at nodes B and Y will invoke an LSP protection switch. This is
> marginally bad, because it extends the outage by some number of
> milliseconds, and it complicates the revert later.
>
> If the path monitoring function has a holddown timer, such that it does not
> invoke a switch until 50 ms of outage, then failures at H or O will not be
> reacted to as quickly as possible.
>
> Instead of performing path monitoring to trigger an LSP-switch, B and Y
> could perform line monitoring, and only switch if failures occur on their
> local segments? But this seems like it opens up a class of failures which
> would not be recovered from.
>
> So it seems to me that the mixing of protection schemes creates a small
> problem, and I wonder what people think about this?
>
> Nik
>
> > -----Original Message-----
> > From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> > Sent: Thursday, May 30, 2002 8:20 AM
> > To: R. Muralidharan
> > Cc: Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET
> > (E-mail)
> > Subject: Re: Sonet Ring provisioning
> >
> >
> > Hi all,
> >
> > Seems we have mixed up a "ring topology" from "ring
> > protection mechanism".
> >
> > * In a general ring topology, *any* recovery mechanism
> > may be used.
> > This may be the underlying transport's BLSR/MSSPRING or
> > UPSR/SNCPRING, or it may be using control plane to set
> > up 1+1 or 1:1.
> > * In a BLSR/MSSPRING ring, the type of protection has already been
> > decided (i.e., BLSR *is* the name of the protection mechanism).
> > Similarly for UPSR/SNCPRING.
> >
> > Thus if we're talking about BLSR/UPSR rings, then the
> > question is: how
> > does the control plane protocols interact (do they interact?)
> > with the
> > underlying BLSR/UPSR, e.g., does the control plane simply treat the
> > *entire* ring as a single node and thus interfaces to
> > existing EMSs to
> > ask for a sub-network connection across the "node", or does
> > the control
> > plane actually see all nodes of the ring and ask individual
> > nodes for an
> > STS-1/VC-3 connection (but note it only asks for the normal
> > channel i.e.
> > one connection, since the protection channel comes by default -- the
> > service is either protected or unprotected but one connection
> > in either
> > case)...
> >
> > Zhi
> >
> >
> > R. Muralidharan wrote:
> >
> > >Hi All,
> > >
> > >My understanding is as follows:
> > >
> > > BLSR or UPSR rings may be already provisioned in the
> > SONET network. The
> > >task using GMPLS is to set up an end to end virtual path, may be
> > >encompassing multiple SONET rings. This virtual path set up
> > is dynamic in
> > >nature and the life of the path may be only for a fixed
> > interval, after
> > >which it would be tore down. When one wants to set up a path
> > through a SONET
> > >ring, one may have to specify whether one wants a 1+1
> > protection path or a
> > >1:N protection path or just an unprotected path. Based on
> > this specification
> > >the GMPLS can discover and set up an appropriate path in a
> > BLSR or an UPSR
> > >ring as the case may be and hence the cost would be optimum.
> > ( assuming that
> > >a 1+1 path would cost more than an unprotected path). As
> > Greg pointed out, I
> > >also believe that the BLSR and UPSR ring configurations
> > would already have
> > >been set up by associated NMS or EMS and advertised. The
> > granularity of the
> > >path that can be set up using GMPLS could a VT1.5 or
> > multiples of them ( VT
> > >Path) or STS-1s (STS Path).
> > >
> > >I have used the words "path" and "virtual path" in generic
> > terms and not in
> > >the SONET or SDH domain definitions.
> > >
> > >Does the above make sense ?
> > >regards,
> > >murali
> > >OSS Systems India
> > >
> > >----- Original Message -----
> > >From: "Bernstein, Greg" <GregB@ciena.com>
> > >To: "'Manoj Agiwal'" <ManojA@netbrahma.com>; "'Ccamp (E-mail)"
> > ><ccamp@ops.ietf.org>
> > >Cc: "mpls@UU. NET (E-mail)" <mpls@UU.NET>
> > >Sent: Wednesday, May 29, 2002 10:28 PM
> > >Subject: RE: Sonet Ring provisioning
> > >
> > >
> > >
> > >
> > >>Hi Manoj, the UPSR and BLSR cases are very different. I'm
> > assuming that
> > >>
> > >>
> > >you
> > >
> > >
> > >>are setting up SONET paths such as STS-1, STS-3c, ...
> > STS-192c or their
> > >>
> > >>
> > >SDH
> > >
> > >
> > >>equivalent.
> > >>Then
> > >>(1) In the BLSR case the protection is at the SONET line
> > layer, i.e.,
> > >>
> > >>
> > >below
> > >
> > >
> > >>the layer of the connection that you are setting
> > up(SONET/SDH are layered
> > >>networks). In this case no special action needs to be
> > taken unless of
> > >>course the entity requesting the connection asked for "enhanced"
> > >>
> > >>
> > >protection
> > >
> > >
> > >>in the setup request.
> > >>
> > >>(2) A UPSR works at the path layer, i.e., like a path layer
> > 1+1, with the
> > >>redundant paths taking different routes around the ring.
> > Hence you are
> > >>actually setting up two connections that have a special
> > relationship with
> > >>each other. This would have to be indicated somehow (tunnel ID or
> > >>something). Some UPSRs may put constraints on the timeslots
> > used too. One
> > >>meta question is why bother signaling around a UPSR versus
> > talking to a
> > >>
> > >>
> > >UPSR
> > >
> > >
> > >>as a separate "protection domain"? There is no way mesh
> > restoration could
> > >>come close to a UPSR's restoration speed (it just selects
> > the better of
> > >>
> > >>
> > >two
> > >
> > >
> > >>signals). Hence I don't understand the benefit signaling
> > around the ring
> > >>
> > >>
> > >in
> > >
> > >
> > >>this case, all vendors have methods for setting up their
> > UPSRs via EMS's
> > >>
> > >>
> > >why
> > >
> > >
> > >>not just interface to those rather than to the individual
> > ring elements...
> > >>
> > >>Greg B.
> > >>
> > >>***********************************
> > >>Dr. Greg M. Bernstein
> > >>Senior Technology Director, Ciena Corporation
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Manoj Agiwal [mailto:ManojA@netbrahma.com]
> > >>Sent: Wednesday, May 29, 2002 2:01 AM
> > >>To: 'Ccamp (E-mail)
> > >>Cc: mpls@UU. NET (E-mail)
> > >>Subject: Sonet Ring provisioning
> > >>
> > >>
> > >>Hi ,
> > >> Do we use GMPLS signaling protocol for configuring
> > Sonet Rings (
> > >>
> > >>
> > >UPSR
> > >
> > >
> > >>/ BLSR ( 2 fiber/4
> > >> fiber ) ?
> > >>
> > >> I was going through certain white papers where there
> > was a mention
> > >>that GMPLS is used as
> > >> a signaling protocol for provisioning mesh topologies only
> > >>.Traditional Sonet rings will be
> > >> replaced by mesh topologies in future .
> > >>
> > >> But there is a section 12.( LSP protection and
> > restoration) in GMPLS
> > >>Architecture which says
> > >> that " Both mesh and ring like topologies are supported "
> > >>
> > >> How do we provision nodes in Sonet ring using GMPLS ?
> > >> Or GMPLS has been designed to provision mesh topologies only.
> > >>
> > >>Regards ,
> > >>Manoj
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> >
> >
begin:vcard
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard