[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Sonet Ring provisioning
Here's my two bits.
It appears to me that there are many ways of representing "restoration
islands",. By restoration islands, I refer to BLSR or vendor specific
mesh etc. As Zhi and Sudheer have pointed out it could be "protected
nodes" or "protected links". But in any case, the way of representing an
"restoration island" depends to a large extent on what kind of a service
the user desires.
Some of the types of services may be:
- end to end 1+1/1:1
- end to end dynamic mesh
- end to end unprotected.
- dynamic mesh going thro' "restoration islands"
For instance, in the network below, (I-J-K-L-M-N), (I1-J1-K1-L1-M1-N1)
and (I11-J11-K11-M11-N11) are BLSR rings, The user must be able to
specify a path from A to Z that could be one of the following:
1. Not routed thro' a BLSR ring
2. routed thro' one BLSR ring
3. Routed thro' two BLSR rings
J1-----K1 J11----K11
/ \ / \
I1 L1--- I11 L11
/ \ / \ / \
/ N1-----M1 N11----M11 \
/ \
/ J------K \
/ / \ \
A------B------H------I L-------O-------Y------Z
\ \ / /
\ N------M F------G
\ /
C---------------D---------E
So the first question we have to answer is what are the kinds of
services we are trying to provide. Is it fully redundant, mesh, mesh +
partially redundant?
-----Original Message-----
From: Sudheer Dharanikota [mailto:sudheer@nayna.com]
Sent: Friday, May 31, 2002 10:32 AM
To: v.sharma@ieee.org
Cc: Zhi-Wei Lin; Suresh Katukam; R. Muralidharan; Bernstein, Greg;
'Manoj Agiwal'; 'Ccamp (E-mail); mpls@UU. NET (E-mail)
Subject: Re: Sonet Ring provisioning
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
>
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]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,
> >
> > 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)
>
> 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
>
> >