Re: Sonet Ring provisioning

[Maarten Vissers <mvissers@lucent.com>]

Suresh,

From the HOVC [STS] layer network the ring provides for HOVC unprotected
connections. I.e. you set up the connection A-B-C-D and inform the MS SPring
[BLSR] ring manager of this connection, and that is it. Some ring managers only
need to be given the ingress and egress nodes, and they will set up the
connection true the ring at the same time as they configure the necessary MS
SPring information in the intermediate switching nodes on the ring.

Because the ring is a MS SPring [BLSR] ring, the HOVC connections are protected.
This MS SPing configuration is however established before any HOVC connection is
routed over it. I.e. it is set up and ready to provide connectivity between its
nodes on the ring. Assume that the ring is a sTM-64 ring. In this case the HOVC
links between any two nodes will have a 32 VC-4 link connections (or 96 VC-3, or
8 VC-4-4c, or 2 VC-4-16c link connections or a mix). 

If extra traffic is supported on this ring then there will be another HOVC link
between any two nodes with the same number of link connections. In this case,
there is a choice to put a connection via the regular HOVC links, or via the
extra traffic HOVC links. In the latter case the connection may get interrupted
when there is a fault in the ring (extra traffic is dropped).

If the ring supports selective MS SPring (NUT feature), then a third HOVC link
between the nodes will exist and the size of the HOVC links is not longer fixed
(in the example to 32). 
I.e. for a sTM-N ring with MS SPring protection
- HOVC link #1 - protected traffic:	0 .. N/2 VC4 link connections
- HOVC link #2 - preemptable traffic:	0 .. N/2 VC4 link connections
- HOVC link #3 - unprotected traffic:	0 .. N VC-4 link connections
Combinations for e.g. STM-64 ring include [link#1, #2, #3]: [32,32,0],
[31,31,2], [30,30,4], etc.

See also the functional model of a MS SPring node in G.783.

Regards,

Maarten



Suresh Katukam wrote:
> 
> Let us say that the BLSR ring topology is as follows:
> 
>       A --- B --- C
>       |           |
>       H           D
>       |           |
>       G --- F --- E
> 
> If one wants to create a LSP from A to D via B, C, then A
> signals to B, B to C, C to D. Everything is fine.
> 
> If B -- C link fails, what happens next?
> 
> 1. Should B and C keep quite and do not tear down
> LSP (because these know that B - C line is protected)?
> How about H, G, F, E, D, C nodes?
> Do these need to know that these are protecting an LSP that
> goes through A to D? What happens if another link G - F fails?
> Do these nodes need to inform B or C or A indicating that
> these cannot protect B - C link anymore so that B can do
> Fast Reroute?
> 
> 2. Should B and C setup a backup LSP (when link fails) around the
> ring? Traffic is not affected during this period. This provides
> a mechanism for nodes involved in LSP can get information
> from nodes that are in backup LSPs.
> 
> I think that there are quite a few issues are not resolved in
> this area and taking a simple view is not going to be sufficient
> when Fast Reroute and other  things come into play.
> 
> Thanks,
> Suresh
> 
> Zhi-Wei Lin wrote:
> >
> > 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