The MPLS WG Archive

[neil.2.harrison@bt.com]

	Kireeti observed:
> However, the point of GMPLS is NOT a peer model.  It is an IP-based
> control plane, leveraging existing work, and the flexibility of a
> peer or overlay or hybrid model.
> 
	The basic argument you are making here Kireeti (and one I saw John
Drake advocate) is that it makes sense not to re-invent the control-plane
(which has been the case historically) for every new user-plane
technology/PDU-type.  I strongly agree with this view.  However, exactly
*which* control-plane aspects one should use is a different question....and
this is essentially the point Darren Freeland was making, and against which
(it appears) some have already make decisions as to what is the right
solution without any real debate of the 'requirements'. 

	I have also tried to make the point (using technical arguments, and
not very successfully it seems) that there are *commercial* issues at play
here and we are not dealing with some greenfield site where an idealistic
solution is viable (even if right, and I am not sure it is)....the simple
fact is that operators like BT will have to support many types of different
client layer.  Ergo, a peer model for operators like ourselves is not
currently a viable option....it's as simple as that.

	Now lets return to the more technical aspects and arguments, since
we still have a duty (as engineers) to be forward looking and evaluate
proposals on their technical merits...even if accountants control the
near/medium-term.

	John (Drake) used the ATM/IP (and the mess of MPOA) as analogous to
the IP/OTN case....so the argument then develops into 'let's use the same
(control-plane) solution for everything' (which is essentially the GMPLS
philosophy).  The assumption in GMPLS is that the key facets of an
(historical) IP control-plane (ie v4 addressing, RSVP signalling (OK CR_LDP
too.....maybe even better for OTN) and an IGP such as OSPF) are the *right*
choices for an OTN (or indeed everything).

	I could now use a great deal of BW up explaining why ATM/IP and
OTN/IP are very different animals.......so I will be as brief as I can be,
and I apologise to any left wondering why I made any of the following points
(come back to me off-line if you need the detail):

	In the ATM/IP case there are compelling reasons to unify the
control-plane with the concept of MPLS....such as:
	-	to avoid the VoXX N^/2 type of gateway problem across
user/control/management/oss planes
	-	to unite a CO and CNLS transfer mode.....though currently
the CO aspect is network-only (so-called control-driven LSPs) due to, quite
correctly, the current predominant type of Internet traffic, ie
short-holding WWW.......but this may not always be the case, esp when clever
applications people start thinking how to use all the BW that the OTN will
provide........think video and possibly long-holding interactive sessions.
This could radically alter the required/dominant transfer mode, and indeed
the role of MPLS.
	{Aside: This could also solve the QoS issues as a by-product,
however it requires an open-mind to see the possibilities.  Hint:  The only
2 truly scalable networks I am aware of (both proved by existence) are the
PSTN and the Internet}
	-	to unify the addressing (the other 3 key facets of the
control-plane, ie routing/discovery technique, signalling protocol and the
special requirements of the signalling network itself are secondary to
addressing)......this is really why MPOA could never work (the details are
clearly more complex than I hint at here, but the essential problem is a
lack of address unification).

	IP and ATM as user-plane PDUs have quite a lot in common (esp at AAL
level):
	-	application interfacing
	-	relatively fast time-constants wrt to network demand
changes......and within this issue is the problem of TE
	-	small granularity user-plane PDU structures....allows
concepts of buffers and differential serving treatment of PDUs

	But as we go down the server layer stack the time-constants change,
ie they increase.  The slowest time-constants are associated with the duct
network...and this really is a network and it is a very important one.  This
is the ultimate expression of real TE (wireless/radio people might argue
with this, but the 'environment of physical occupancy' is the essential
feature) and this is where the availability bound of all client layers is
determined.  The OTN we should note, is just above the duct network, ie it
is dealing in coarse BW granularities and longish time-constants (compared
to its finer BW granularity client layers).

	So what are the essential features of the *user-plane* of the OTN?
	-	no practical buffering....so we can forget IP, ATM, FR, or
indeed any type of binary frame/packet/cell/PDU structure as being *an
essential driver*.  Or, perhaps put another more obvious way, the OTN
doesn't do DiffServ.
	-	it is CO/cct-sw and user-plane transparent....so it can't
identify PDU boundaries (I have heard some people say this about ATM, but
the PTI of the cell O/H in AAL5 does this)
	-	it will have (for commercial reasons) lots of legacy/new
client networks, and indeed peer coarse managed BW services, it will have to
support....and customers will also demand this, let alone being an operator
*must have*.

	So what does this mean wrt to its control-plane?
	-	well its addressing clearly has to be disjoint from any
client addressing space ('server layer trails = client layer links').  v4 is
already creaking in the IP layer.  v4 has also had to learn the lessons of
aggregation and the need for routing and topology to have close linkages (ie
CIDR and users having to take address stems from ISPs)  So why would v4 be
an 'obvious' choice for the OTN?
	-	we are dealing with a CO/cct-sw fabric whose clients, in
terms of PDU structure, are almost irrelevant....so what is the best
signalling protocol for this environment?  It is certainly not clear to me,
and I think many others, why RSVP would come out tops in any such
evaluation.
	-	routing/discovery.......I'm not sure what is best here for
the OTN.  But there is much to be learnt from both the Internet world and
the Telephony world on what would be the best solution here.  Though I have
to say here that I would want this restricted to an OTN layer problem since
I simply don't understand how, in an environment of multiple clients, I can
have any (for want of a better expression) a 'distributed/unified
routing/discovery protocol across multiple layers'...and with all the
scalability/client-priority/etc issues this throws up.

	So, in conclusion, to say that 'an IP control plane' (whatever that
actually means) is appropriate for the OTN simply does not compute with me
at the present time based on my own analysis of the problem-space.

	Neil