Re: Sonet Ring provisioning

[Sudheer Dharanikota <sudheer@nayna.com>]

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
>
> >