Subject: RE: GMPLS - Hierarchies

From: [email-masked]
Date: Fri, 8 Dec 2000 14:48:43 -0000

Juergen....you raise another good point....but this time wrt to the
user-plane and the fact there are just too many layers.  All are
networks......and what I mean by this they are all potentially true L3
entities (forget the silly 'there is only one L3' OSI  definition), and so
could have addressing/signalling/routings/etc, ie a control-plane.  But
their existence is historic.  It would be nice to reduce the number of layer
networks and we should do this if possible for two technical reasons (there
are clear cost reasons also, both in terms of
staff-skills/training/spares/etc and direct efficency of
utilisation/applying resotration/etc):

1	At an application interfacing level we don't want lots of different
layer networks all interfacing with the same application, eg VoXX....where
XX could be ATM (AAL,1,2,5), IP, MPLS, FR, PSTN, etc.....this creates an
O(N^2) I/W problem across all facets of user/control/management/OSS planes.
What would be neat here is to unify both a CO and CNLS transfer mode under
the *same* addressing regime.  Couldn't do it with ATM because of this (ie
address translation is killer).....but we can with MPLS.....just have a
think about this for a while, it simplifies some QoS problems and
compression problems.  Neither a pure CO nor CNLS approach can do everything
well....we really need both.  The glut of BW the OTN unleashes may be the
catalyst to invoke this.  Not viable now (eg nature of most IP traffic) but
who knows in say 3-5 years?  Note here that I am very pro a unified
control-plane for the two CO/CNLS modes at an *application interfacing*
level.

2	The issue you are raising is more about the many different types of
layer network that provide the large administative BW network.  We need a
layer network which gives large BW quanta admin for many reasons, eg provide
aggregation (ie muxing) for higher level application interfacing layers,
grandfather legacy layers (these are all those you identify...and where the
goal should be to remove these over time), provide large BW services to
wholesale customers (eg other operators or enterprises to build their own
private networks).  This is where the generalised MPLS debate/arguments have
kicked-in wrt to peer vs overlay model.....and I emphasise I really don't
want to inflame this one again on mail.  Indeed, the only point I want to
make here is that for these very reasons we can't use the same mindset as I
alluded to above in 1, ie CO/CNLS unification of the control-plane at an
application interfacing level......the problem is quite different.

So there is no real magic answer to you question Juergen.....we have to
grandfather these layer networks and look to reduce them over time (ditto at
an application-interfacing in my opinion).  But I pray we have the sense not
to create too many layer networks for the OTN....noting that in a prior mail
I made the analogy that the MPLS user-plane shim header was like a digital
wrapper (ie non-fixed hierarchy) and in my view we need something like this
for the OTN.  However, I know others have different views on this, so I am
not looking to open a debate on this issue either...I am just making an
observation of analogy for people to think about.

Neil

> -----Original Message-----
> From:	Heiles Juergen [SMTP:[email-masked]]
> Sent:	Friday, December 08, 2000 12:18 PM
> To:	'Yangguang Xu'; [email-masked]; [email-masked]
> Subject:	RE: GMPLS - Hierarchies
> 
> 	[Heiles Juergen]  Hi Yanguang, 
> 
> > Juergen,
> > 
> > Agree in concept,
> > 
> > LSPs don't have to starts and ends on the same LSR type. A not ugly
> example is,
> > in circuit switched transport network, a T1 equivalent LSP can go
> through a TDM
> > mux and then a SONET box capable of low order switch.
> > 
> >  
> 	[Heiles Juergen]  your example raises another question I have in my
> mind for some time. The T1 and the lower order VT1.5/VC-11 belong to
> different layer networks. The VC-11 is the server for the T1 signal
> accoording to the functional architecture. So basically we have two LSPs,
> a T1 and a VT1.5/VC-11 LSP with the T1 LSP partially transported within
> the VT1.5/VC-11 LSP. It is a one-to-one client/server relationship as the
> VT1.5/VC-11 transports only one T1 signal. Due to the one-to-one
> relationship it is possible to treat the two LSPs as one for the path
> setup. A more extrem example is a VC-4-64c (STS-192c-SPE) transported via
> an Optical Channel. The layer structure could be VC-4-64c -> MS64 -> RS64
> -> ODU2 -> OCh, all with a one-to-one client/server relationship.
> Cross-Connections would be possible at the VC-4-64c level (SDH/TDM
> cross-connect), the RS64/OS64 level (fiber cross-connect), the ODU2 level
> (ODU/TDM corss-connect) and OCh level (lambda cross-connect). Do we set up
> 
> one LSP or multiple LSPs, one for each layer and pass the set-up request
> from the client to the server?
> 	If we have a many-to-one client/server relationship (multiplexing)
> it is clear that we generate a new LSP. Note that a layer network can have
> both one-to-one and many-to-one relationships, both as a server and as a
> client (e.g. a STS-1-SPE/VC-3 can transport a single DS3 or multiple
> VT1.5/VC-11).
> 	Any view on that.
> 
>

---

From: Yangguang Xu <[email-masked]>
Date: Fri, 08 Dec 2000 10:08:48 -0500

Neil and all,

This thread of discussion raised many important and interesting issues. I've
touched some issues in the inter-domain section of my I-D
ietf-xu-mpls-ipo-gmpls-arch-00.txt. 
The inter-domain (technology domain) issue deserve us much attention and study. 

If all of us are going to be at San Diego, we can arrange a discussion there and
put our thoughts together. Sounds good?

Thanks,

Yangguang