Re: Sonet Ring provisioning

[Maarten Vissers <mvissers@lucent.com>]

Vishal,

The answer to this issue is layer networking. I.e. the HOVC layer network sees
the MS SPring protected ring as a set of HOVC fabrics and (1, 2 or 3 types of)
interconnecting HOVC links. 
The HOVC fabrics have a restriction; there is no time slot interchange possible
between the two main links. I.e. the link connection in those two links must
have the same number.

The HOVC control plane selects in which type of HOVC link (protected,
unprotected, preemptable) the new connection has to be created, and then routes
this connection through the HOVC fabrics and links.

The MS SPring [BLSR] control function within the ring network elements (if
supported) will have to populate the ring nodes with the appropriate further
information to run the ring, but this is outside the HOVC control plane's view.

From a HOVC control plane, this is almost a trivial issue... only constraint is
no "time slot interchange" on ring HOVC links.

Regards,

Maarten

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.

And may be supported by MSn control plane in the future...

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

GMPLS is quite complete; only item is if it can handle the "no time slot
interchange" case. The rest is taken care of in setting up the HOVC layer
network topology... i.e. you must use GMPLS in a layered networking manner...

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