Subject: RE: Sonet Ring provisioning

From: "Bernstein, Greg" <[email-masked]>
Date: Wed, 29 May 2002 09:58:02 -0700

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:[email-masked]]
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

---

From: "R. Muralidharan" <[email-masked]>
Date: Thu, 30 May 2002 14:18:46 +0530

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" <[email-masked]>
To: "'Manoj Agiwal'" <[email-masked]>; "'Ccamp (E-mail)"
<[email-masked]>
Cc: "mpls@UU. NET (E-mail)" <[email-masked]>
Sent: Wednesday, May 29, 2002 10:28 PM
Subject: RE: Sonet Ring provisioning

---

From: Zhi-Wei Lin <[email-masked]>
Date: Thu, 30 May 2002 08:20:20 -0400

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 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
>  
>
>>course the entity requesting the connection asked for "enhanced"
>>    
>>
>protection
>  
>
>>in the setup request.
>>
>>meta question is why bother signaling around a UPSR versus talking to a
>>    
>>
>UPSR
>  
>
>>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
>  
>
>>      Do we use GMPLS signaling protocol for configuring Sonet Rings (
>>    
>>
>UPSR
>  
>
>>/ BLSR ( 2 fiber/4
>>      fiber ) ?
>>

---

From: Suresh Katukam <[email-masked]>
Date: Thu, 30 May 2002 11:23:01 -0700

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

---

From: Zhi-Wei Lin <[email-masked]>
Date: Thu, 30 May 2002 14:54:21 -0400

Hi Suresh,

Yes agree this is very complex if you try to create too much 
dependencies between control plane and transport plane protection 
interactions. That is why my simplistic approach:

    * Control plane sees the entire ring as offering "highly available"
      connections
    * Control plane sets up a single connection across this ring
      "sub-network" (if you think this about this, the entire ring can
      actually be treated by a control plane controller as a single node
      where the BLSR ring nodes may be thought of as aggregate ports on
      the single node)
    * The ring sub-network, by virtue of providing the protection and
      knowing *exactly* how protection is provided can set up the
      protection channel automatically (but control plane need not know
      this as it is irrelevant to the control plane -- it only needs to
      know that the single connection is protected)

Of course there will be additional constraints placed by the ring, such 
as a flag to indicate the availability of "highly available" 
connections, whether or not to enable this highly available connection 
(if not enabled then you may be using the NUT feature of BLSR e.g.), 
whether the same timeslot must be used, whether ring switching or span 
switching is supported (and enabled), whether traffic should be carried 
as "best effort" (e.g., as extra traffic on the BLSR), etc. etc.

Thus in your example, if link B-C fails, so what? the underlying BLSR 
protects this connection. The control plane sees its A-D connection as 
been up all the time (the little transport plane interruption probably 
translates to a packet delay). Also by virtue that this is a BLSR ring, 
nodes H, G, F, E knows exactly which link it is protecting (it's part of 
the BLSR protocol operation).

If another link G-F fails, then the entire ring has become segmented, 
and thus *any* traffic going through this ring is shot (except those 
that are contained within each segment). Then you either declare the 
connection "dead" or if you're offering an end-to-end restoration on top 
of the ring, you might try re-routing the LSP. But this is a separate 
issue from how the rings work (all the ring nodes would know that the 
ring is segmented from the K1/K2 byte info exchanges in a BLSR -- 
doesn't need control plane to tell it anything), but more to do with 
what mechanisms control plane has for restoration. The interactions of 
course may be the holdoff timer that Greg mentioned.

Zhi

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 31 May 2002 14:45:54 +0200

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

---

From: Sudheer Dharanikota <[email-masked]>
Date: Fri, 31 May 2002 10:31:45 -0700

Hi All:

This is very interesting discussion.

Some of the people on this discussion list already looked
at some of these issues. Please refer to draft-many-ccamp-srg-01.txt
for more information.

Here is my opinion:

Transport networks provide their own protection mechanisms such
as the rings under discussion. As others pointed out it makes good
sense to use them for faster restoration times. These rings may
be created through NMS/EMS - this is not a concern to the control
plane.

The real problem is how to represent this ring topology in the control
plane for the path computation. Well one proposal as mentioned by
Zhi was to represent by a logical node with node capability being
"highly protected node" (inheriting the property of the ring). Another
way to see this, as mentioned in the srg draft is to represent by
point-to-multi point links with the exit points to the ring as the
terminating points of the links and define the same "highly protected"
property on the links (unlike on the node). Now that we have the
links and link property we can use it in the path computation.
Once path is computed it is the nodes, which are on the ring and
participate in the control plane, to make a connection between
the end points. Please refer to the above draft or
http://www.cs.odu.edu/~sudheer/technical/papers/journal/SRGPaper.pdf

- sudheer

Vishal Sharma wrote:

> Zhi and all,
>
> Great discussion! I'm glad we're finally discussing some of these
> issues, and highlighting that mix inherent ring protection with
> the control domain mechanisms is non-trivial.
>
> Comments in-line.
>
> -Vishal
>
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Zhi-Wei Lin
> > Sent: Thursday, May 30, 2002 11:54 AM
> > To: Suresh Katukam
> > Cc: R. Muralidharan; Bernstein, Greg; 'Manoj Agiwal'; 'Ccamp (E-mail);
> > mpls@UU. NET (E-mail)
> > Subject: Re: Sonet Ring provisioning
> >
> >
> > Hi Suresh,
> >
> What mechanism will the ring use to setup the internal protection channel?
>
> Will it require EMS/NMS intervention, as proposed on this thread earlier,
> or will there be another sequence of control plane messages (initiated
> internal to the ring) to set this path up. The latter would be prefereable
> if the objective is to have fully-automated path setup (otherwise, we
> have EMS/NMS intervention for the ring), but it does complicate the
> control plane protocols (since a new sequence of setup steps may
> have to be initiated internal to each ring on the path of the end-to-end
> circuit/trail that is being setup.
>
> -Vishal
>
> >

---

From: Suresh Katukam <[email-masked]>
Date: Fri, 31 May 2002 10:34:33 -0700

All,

Comments in-line..

> circuit/trail that is being setup.

Yes, this is where the most of the problems are. I was referring to this
where GMPLS based messages will be used to setup a path around the ring.
I was trying to bring up the issues that may come up during the path setup
in the ring. 

Zhi and Maartin, Please let us know your thoughts on this.

Thanks,
Suresh

---

From: Sudheer Dharanikota <[email-masked]>
Date: Fri, 31 May 2002 11:01:18 -0700

Vishal:

I agree that representation, path computation and path setup
are three problems that we need to solve here. Please refer to
the paper I refered to address the first two problems.
In the GMPLS P&R design team we are looking at some of
the issues related to the path setup. In the current version we
are not looking at rings, which we will do later if there is
clear consensus to address them. Extra traffic is one of the
subjects we will be addressing (again for linear topologies)
in the first release.

- sudheer

Vishal Sharma wrote:

> Sudheer,
>
> While I agree that representing nodes/domains/rings etc. is an important
> problem, I think there are two issues being mixed below.
>
> One is the problem of the initial configuration of the UPSR/BLSR ring,
> which is clearly (today) an NMS/EMS operation.
>
> The other is of dynamically setting up trails on the ring. It is this
> latter problem that falls under the purview of an automated control
> plane, and is the one being discussed. This will involve the control plane,
> and the issue there, as Suresh pointed out, is how does one deal with
> mixed mesh-ring networks, similar, for example, to the topology drawn by
> Nik Langrind.
>
> In that case, I don't think the GMPLS specifications are complete enough
> to enable one to accomplish path setup. There are several issues
> there, including the difficulty of deciding exactly the process by
> which path setup on rings will be handled, and how the various items
> that Zhi outlined in an earlier email (ring/span switching supported?,
> extra traffic supported? etc.) will be handled.
>
> I see the issue of representation as somewhat tied to how one does
> path setup above. That will dictate how the rings and their nodes/links
> should be represented in the routing protocols, and how path computation
> will take them into account.
>
> Some of these issues were discussed by us in a draft a while back
> http://search.ietf.org/internet-drafts/draft-mannie-mpls-sdh-ospf-isis-02.tx
> t
>
> -Vishal
>
> > From: Sudheer Dharanikota [mailto:[email-masked]]
> > Sent: Friday, May 31, 2002 10:32 AM
> > To: [email-masked]
> > Cc: Zhi-Wei Lin; Suresh Katukam; R. Muralidharan; Bernstein, Greg;
> > 'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET (E-mail)

---

From: "Vishal Sharma" <[email-masked]>
Date: Fri, 31 May 2002 10:54:34 -0700

Sudheer,

-Vishal

---

From: "Vishal Sharma" <[email-masked]>
Date: Fri, 31 May 2002 09:49:33 -0700

Zhi and all,

Comments in-line.

-Vishal

-Vishal