[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sonet Ring provisioning
Good points Vikram. Since we cannot standardize services,
we need to keep them in min while proposing the mechanisms.
This is waht we are trying to do also.
Vikram Anantha wrote:
> 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"
These restoration islands are called risk domains in
draft-many-ccamp-srg-01.txt.
>
>
> 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
>
These can be again achieved through the SRG draft. Please note the
discussion on the inclusive and exclusive constraints.
>
> 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?
>
Well we cannot standardize services. So the approach we are taking is
what is the scope of this GMPLS P&R work. Until now we are concentrating
on the mesh restoration. We need to consider ring protection and
using server layer protection as near future enhancements, provided
we get more support from the working group discussions.
- sudheer
>
> -----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
> >
> > >