Subject: RE: [mpls] what routing protocols have what to do with QoS?

From: "Peter Ashwood-Smith" <[email-masked]>
Date: Sat, 13 Nov 2004 18:45:49 -0500

I like Kireeti's better ;) ... I'm reminded of that wonderful chapter in
Hitch Hiker's guide ... Hopefully MPLS won't disappear in a 'puff of logic'
;)

I used to present MPLS as an L3 protocol controlling an L2.5 data path.
I.e. between Ethernet and IP.

GMPLS was described as an L3 protocol controlling an L0(lambda) or L1(TDM)
data path.

Many people get confused by this separation of control/data plane when
learning about (G)MPLS.

Peter 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, November 13, 2004 5:49 PM
To: Kireeti Kompella
Cc: [email-masked]
Subject: Re: [mpls] what routing protocols have what to do with QoS? 

Kireeti,

> On Thu, 11 Nov 2004, SP wrote:
> 
> > since MPLS over ip over ethernet...
> > and since ip over ethernet (layer 3 over layer 2)...
> 
> Let MPLS be Layer N.
> 
> By the above, N > 3.
> 
> You can also carry Ethernet over MPLS,
> 
> Hence, 2 > N.
> 
> Therefore, 2 > 3.  QED.
> 
> Hope that helps :-)

Just to help more, here are few points from one of my presentations on
(G)MPLS:

(G)MPLS is not a Network Layer on its own, as it does not have routing and
addressing on its own - it uses IP addressing + IP routing (with
extensions)

(G)MPLS is not a Link Layer because MPLS works over various Link Layer
technologies (e.g., SONET, Ethernet, ATM, etc.)

(G)MPLS is not a Layer in the OSIRM (OSI Reference Model) sense as it does
not have a single format for transport of the data from the layer above
(e.g., (G)MPLS uses "shim" on SONET, VCI/VPI on ATM, time slot on TDM,
lambda on OXC, etc...).

Yakov.

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: [email-masked]
Date: Mon, 15 Nov 2004 09:27:35 -0000

Kireeti...what a lovely demonstration of the meaningless L1, L2, L3
classification.  The only classification that makes any sense is the
modal one, ie co-cs, co-ps and cl-ps.....and then an understanding that
these modes are not the same, so any '1 size fits all' treatment across
all modes makes no sense.  Indeed, it is the differences that are the
important bits......not sure many folks get this however.  All these
modes are 'peer L3 networks' in the unreal and restricted OSI 'L3
network layer' view of the networking world.

BTW - There are no QoS classes in the co-cs mode.....this is one of its
key defining differences.  Some others are:
-	control/management must be OOB....this is not an option in this
mode
-	can't violate the connectivity constraints of the co mode, ie
merging is simply not possible here
-	one always has a fixed/known hierarchy in the data-plane...so
one can force functional decoupling between layer networks.
All of these are very important properties of the co-cs mode......you
don't find them *forced* in the cl-ps mode, and because of this one can
sure screw them up in the co-ps mode.  If anyone is wondering 'why' this
is, it is down to the nature of how the link-connections are
defined/manifested in the co-cs mode, ie here they must take on a
real/physical property of either time, space or frequency and the
bit-rate must be fixed at a known value (cf the co-ps mode where the
link-connection IDs are simply abstract 'numbers').

Further:
-	given a network layer N inherits the performance of the layer
N-1 network (ie link-connections in layer N are provided by trails in
Layer N-1....theis is the fundamental property (in G.805) that defines
layer N topology creation);
-	this is a recursive behaviour to the duct;
-	there are (currently at least) no rules for governing what
client/server relationship can exist between pairs of modes (there are 9
permutations);
-	there are no rules govening *how many* client/server instances
can exist in an instantiation of a network arch that delivers some
end-system application (ie right at the top of the stack);
.......then its clear that trying to define any end-end network
performance objectives and then trying to apportion these to partitions
of this (eg operator domains) in any meaningful/fair manner seems an
impossible task at the current time.  Thus, any talk of 'QoS' is also a
rather meaningless exercise.

BTW - If folks were more familar with functional architecture (ie
G.805/809 stuff) all the above would be obvious....I saw some of the
later posts and its clear to me folks are very confused about layer
networks.  Very seriously....please have a look at chapter 3 of
Reid/Sexton ('BB networking') as this will help.

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kireeti Kompella
> Sent: 12 November 2004 21:00
> To: SP
> Cc: [email-masked]
> Kireeti.
> -------

---

From: [email-masked]
Date: Mon, 15 Nov 2004 12:25:15 -0000

Yakov,

> 
> Just to help more, here are few points from one of my 
> presentations on (G)MPLS:
> 
> (G)MPLS is not a Network Layer on its own, as it does not 
> have routing and addressing on its own - it uses IP 
> addressing + IP routing (with
> extensions)
NH=> You talk of addressing here Yakov and yes we can use IP (v4 or v6)
structured addresses all over the place....does not mean to say they
belong to an IP layer network however.  For example, I can use IP v4
structured addressing for an SDH VC4 access point and an SDH VC12 access
point (or the access points in any other layer network for that
matter)......but I for sure cannot connect these together as they belong
to different layer networks.  {A layer network is characterised by the
set of addressable access points which can be connected together.}

Addressing is bound to access points.  So even if folks use the same
addressing format they come from difference spaces.

Further, and as folks have discovered with GMPLS, or more accurately due
to the co-cs mode, the traffic data-plane network (co-cs) must be
disjoint from the control (or management) data-plane network (which in
all probability uses the cl-ps mode).  These 2 (at least) networks in
the same technology (say SDH) have quite different addressing
requirements.
> 
> (G)MPLS is not a Link Layer because MPLS works over various 
> Link Layer technologies (e.g., SONET, Ethernet, ATM, etc.)
NH=> (The control-plane of) GMPLS looks like it does because of the
co-cs mode.  The co-cs mode forces certain things on the network design:
-	there are no QoS classes in the co-cs mode
-	the control/management protocols must be run OOB wrt the traffic
in the co-cs mode....rather an attractive consequence for many reasons,
esp security.
-	the connectivity requirements of the co mode cannot be violated,
ie no mp2p allowed.....this also means the defects are different to
either the cl-ps or co-ps modes
-	the traffic data-plane must retain a fixed/known hierarchy in
the co-cs mode.  Now a word on MPLS is important here.  The 'shim' of
MPLS creates a digital wrapper behaviour in the data-plane of the co-ps
mode, ie there is no fixed/known hierarchy.  This is really neat in some
respects (esp OAM) but it does create some issues when we want to run an
MPLS network belonging to one operator over an MPLS network belonging to
another operator and retain full commercial/functional isolation.  This
is not a problem in GMPLS.....but its not because this was an a priori
design criteria of GMPLS, its a forced imposition of the co-cs mode.

So from a data-plane viewpoint GMPLS and MPLS are not at all alike.
> 
> (G)MPLS is not a Layer in the OSIRM (OSI Reference Model) 
> sense as it does not have a single format for transport of 
> the data from the layer above (e.g., (G)MPLS uses "shim" on 
> SONET, VCI/VPI on ATM, time slot on TDM, lambda on OXC, etc...).
NH=> The OSIRM is not a reflection of reality.  It has, however, led to
a great deal of confusion since folks think there is only ever 1
'network layer'.   There are lots of network layers (or more accurately
layer networks), and the only thing that roughly classifies them in any
sensible way is whether technology X belongs to the cl-ps mode, the
co-ps mode or the co-cs mode....and its is the differences in the modal
behaviours that are the important bits.  IMO functional convergence
within a mode makes a great deal of sense, but not across them (esp when
we need to take the commercial operating requirements of carriers into
account).

regards, Neil