[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GMPLS Sonet extensions
Diego,
Indeed, each switched layer network (e.g. LOVC, HOVC, ODU1, ODU2, ODU3
and OCh) will have its own (instance of) control plane.
Each switched layer network runs a copy of the generic routing protocol;
it does so within the boundaries of the switched layer network.
Within each switched layer network you will find UNI, E-NNI and I-NNI
interfaces due to partitioning of a switched layer network. Topology
information is exchanged only via I-NNI interfaces. E-NNI interfaces on
the other hand only provide reachability information.
For the case an MPLS router is from a different organisation than the
transport network, it is connected either via a MPLS-UNI or MPLS-E-NNI
interface. For the case the MPLS router is at the edge of a MPLS-VPN,
the interface will be an MPLS-I-NNI.
For the server layers within the MPLS router (e.g. HOVC and STM-N
section layers) the interface relation is to be determined independent
of the MPLS interface relationship. E.g. an MPLS-I-NNI can be combined
(on the same fiber) with an HOVC-UNI or HOVC-E-NNI. so it migth be that
at MPLS level full topology information is exchanged (MPLS-I-NNI), where
as at the HOVC layer entwork only reachability information is available
in the MPLS router (HOVC-E-NNI).
The MPLS router should not be concerned at all about the routing of the
HOVC signal (e.g. VC-4-16c/STS-48c) which provides the 2.5G MPLS link
between two adjacent MPLS routers. For the case an additional 2.5G MPLS
link between is needed between MPLS router A and MPLS router B, router A
needs to have knowledge of router B's address/name only to request a
VC-4-16c/STS-48c connection through the transport network. The switched
HOVC (transport) network will take care of the connection setup.
And even if two diverse routed connections are required (e.g. to support
VC-4-16c SNC protection within the A and B MPLS routers), MPLS router A
needs to request only the creation of 2 VC-4-16c connections with the
constraint of being diversely routed. The switched HOVC network will be
able to provide these two connections diversely routed between A and B
routers.
At the moment, I recognise two connection types in a layer network:
- native connections and
- client connections.
Example: within a HOVC layer network a STS1 or VC-4 connection is a
native connection, and a DS3 connection or a LOVC link is a client
connection. A client connection is supported by the HOVC layer network
after adapting it to the layer network signal type (i.e. STS1 (to
support DS3), STS1 or VC4 (to support LOVC link)). The client connection
can have a
- 1:1,
- 1:n,
- n:1
relationship with the underlying layer network signal.
Example: DS3 to STS-1 has a 1:1 relationship, a LOVC to VC-4 has a n:1
relationship and a 450 Mbit/s ethernet connection to VC-4-3v has a 1:n
relationship.
With client connections, an I-NNI is almost per definition not possible
(you go outside the layer network). Nevertheless, some people consider
the special 1:1 case as an area where an I-NNI could be deployed; of
course not for the case of DS3 -> STS1, but for the case of
STS-48c/VC-4-16c -> OC-48/STM-16 -> OCh2G5 or ODU1 and STS-192c/VC-4-64c
-> OC-192/STM-64 -> OCh10G or ODU2. The OC-48/STM-16 is a port to the
HOVC layer network and a client signal to the OCh and ODU1 layer
networks, but as the 2G5 STS48c fits the 2G5 OC48 and fits the 2G5
wavelenght it is easy to think to be within one and the same layer
network. Personally, I believe that such very special case looks much
brighter than it is in the long term. I.e. don't declare very special
cases to be the common ones; keep those as very special cases, best even
keep those as regular cases obeying to the generic rules.
Client connections as such have UNI or E-NNI interface relationships
over which reachability information is offered at best. This is the case
for both "horizontal client connections" (e.g. a DS3 over a HOVC/STS
layer entwork) as well as "vertical client connections" (e.g. a LOVC
link over a HOVC/STS layer network).
Regards,
Maarten
Diego Caviglia wrote:
>
> 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.
Agree.
> 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.
Agree. One note however, operators have indicated that they would like
to deploy policies in the NE agent which may include some thresholds,
before it decides to change the topology of the layer network. E.g.
topology is not extended unless X calls failed. On the other hand, the
NE agent may have scheduled topology changes; e.g. at the begin of busy
hour extra links are added or bandwidth of existing link is extended,
and at the end of busy hour the reverse is happening.
>
> 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.
UNI or E-NNI.
>
> 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
> > >
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