[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GMPLS Sonet extensions





Maarten,
                    I agree in principle with you but this means it would be
necessary to have a routing protocol for each layer doesn't it?

One  of  the  initial  reasons  for  (G)MPLS is to unify the control plane, your
layered view of the network implies again the separation of the control planes.

The  Transport  Network is very different from a flat IP network and layering in
TN is implicit.

If  I  understood your model correctly the MPLS Router only views, Access Groups
and  links  to  other  MPLS Routers. If there are free resources between the two
routers  the TE process calculates, accordingly to some rules, the best path. If
there are no resources a call to the Network Engineering agent is performed, the
NE  makes a call to the TE of the SONET layer in order to provide a trail to the
MPLS layer (this procedure is repeated until available resources are created for
the MPLS router connection). This trail modifies the topology at the MPLS layer.

If  my  understanding is correct and we want to implement an automated TN a sort
of UNI has to be put between the NE at layer N and the TE at layer N-1.

Maybe this will create some problems, on the other hand, as Maarten pointed out,
flat  networks  won't  work due the huge amount of routing information that they
have to carry.

Regards

Diego






Maarten Vissers <mvissers@lucent.com> on 11/06/2001 13.16.52
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:      Susumu Yoneda <yone@japan-telecom.co.jp>            
                                                              
 cc:      v.sharma@ieee.org, Jimmy Gendron                    
          <jgendron@hyperchip.com>, ccamp@ops.ietf.org(bcc:   
          Diego Caviglia/MAIN/MC1)                            
                                                              
                                                              
                                                              
 Subject: Re: GMPLS Sonet extensions                          
                                                              







Sharma,

"flat" set up is the route to disaster... simply consider a switched
transport network with switching levels at VT1.5, VC-12, VC-3/STS-1,
VC-4/STS-3c, VC-4-Xc/STS-Xc, ODU1, ODU2, ODU3, OCh and perhaps also DS0,
MPLS, ATM VP, ATM VC, ... etc. Flat would imply that every equipment
would get information of all these levels... an absolute disaster in a
world wide switched transport network would be the result.

Therefore, there is this layering in which a server layer network
provides bandwidth to its client layer entworks. the client layer
networks see this bandwidth as kind of "fixed" bandwidth over which they
can route their signals.

A separate entity (I called it "network engineering") is looking over
the shoulder of the call setup process to see if more bandwidth is
needed and when it would be needed or not longer required. But today,
this separate entity is not part of the control plane; it is in the
management plane.

Regards,

Maarten

Susumu Yoneda wrote:
>
> Sharma,
>
> Thank you for letting me know your presentation material which looks very
> interesting. It seems to me that a layered setup would make a sense.
> However, users may want to have a "flat" setup. Therefore, lower setups
> would not be seen by users?
>
> -----Original Message-----
> From: Vishal Sharma [mailto:vsharma87@yahoo.com]
> Sent: Saturday, June 09, 2001 11:06 AM
> To: 'Susumu Yoneda'; Jimmy Gendron; ccamp@ops.ietf.org
> Subject: RE: GMPLS Sonet extensions
>
> Jimmy, Susumu,
>
> Your idea (assuming a peer model) is basically correct. Since all nodes
> have the same view of the network, you could compute an ERO at the
> ingress router and have the PATH message follow the hop-by-hop route
> to the egress router.
> (Note, however, that the PATH message will travel
> on the out-of-band IP control network; therefore, it would be non-associated
> signaling.)
>
> Also, Susumu, if the peer model is in effect, then all messges will,
> in fact, have to be shared by all nodes, since that is precisely what
> the "peer model" implies.
>
> But you do have to be careful about what "LSP" you are requesting, since the
> characteristics of the requested LSP are not interpreted in the same way by
> the
> various pieces of equipment in your figure. (A SONET ADM requires a
> different
> way of defining a circuit than an IP router or an OXC.)
> Therefore, one possibility would be to do a "layered setup", where an LSP
> at the lower layer is setup before the PATH message at the higher layer
> is tunnelled over it or allowed to propagate further.
>
> For example, when the PATH message for the packet
> LSP arrives at the SONET ADM, the peer SONET ADMs would have to setup
> a corresponding SONET circuit between themselves, and then either tunnel
> the PATH message for the packet LSP over this circuit, or (assuming your
> out-of-band network), at that time, allow the PATH message for the packet
> LSP to propagate to the next MPLS router. (The setting up of the SONET
> channel, likewise, would be a recursive process, with the OXC first setting
> up an optical lightpath between themselves, and tunneling the request to
> set up the SONET channel over it, once that lightpath is setup.)
>
> A more detailed discussion of this subject, with corresponding animations
> and figures, that you may also find helpful is available in a talk I gave at
> MPLSCon'01, and can be found at:
> http://www.mplscon.com/missing_presentations.htm
> (Dynamic path establishment in MPLS-controlled multi-service networks.)
>
> -Vishal
>
> On Friday, June 08, 2001 6:00 PM, Susumu Yoneda
> [SMTP:yone@japan-telecom.co.jp]
> wrote:
> > Hi,
> >
> > I also assume that there would be an out-of-band signalling network based
> on
> > a suite of GMPLS protocols including LMP. I think there will be issues to
> > address whether all messages will be shared by all nodes, i.e router,
> > SDH/SONET, and OXC or not. This will be a part of security issues.
> > -------------------------------
> > Susumu Yoneda   tel +81 3 5540 8493
> > Japan Telecom    fax +81 3 5540 8485
> > Information & Communication Labs.
> > e-mail  yone@japan-telecom.co.jp
> > -------------------------------
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf
> Of
> > Jimmy Gendron
> > Sent: Friday, June 08, 2001 10:01 PM
> > To: 'ccamp@ops.ietf.org'
> > Subject: GMPLS Sonet extensions
> >
> >
> > Hi,
> >
> > I used to read almost all stuff regarding GMPLS since a week. I understand
> > most of the architecture, but I still have a question since the beginning;
> > as an unified control plane, how do the routing/signaling protocols
> exchange
> > informations on a configuration like this:
> >
> > MPLS Router -----> SONET ADM ------> OXC  -----> WDM ----------- WDM
> > -------> OXC --------> SONET ADM --------> MPLS Router
> > (Ingress)
> >
> > Its a basic point to point configuration, but it will allow me to
> understand
> > the basic features of GMPLS. If I want to create an MPLS LSP between the
> two
> > MPLS routers, how do the RSVP PATH message is sent to the network?
> (Assuming
> > that we have an out-of-band IP control network running LMP)
> >
> > My guess is that the PATH message will leave the ingress router with a
> PATH
> > message with a calculated ERO. It assumes that the network is in respect
> > with the peer model...everyone have the same routing table and know the
> > actual network topology. So, my PATH message will follow the CSPF (ERO)
> and
> > go to the egress router. Am I right?
> >
> > Best regards,
> >
> > Jimmy Gendron
> >

mvissers.vcf