Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)

[<[e-mail]>]

Kireeti,

I'm not surprised you are confused.  Let me try and shed a little light on the key underlying arch principles at play here.....


'Time' is a key resource dimension in networking ('space' is another one).  There are 2 main ways we can carve-up and label a time resource and so allocate layer network resource to many (client) users:

1	regular time-slices of (i) known starting epoch and (ii) known duration.
2	irregular time-slices of (i) variable starting epoch and (ii) variable duration

The former leads to the co-cs mode network technologies.  A forwarding label now becomes an implicit position in time (the 'time-slot') and the resource provided is fixed (since the duration is a precise number of bits at some bit rate...a bit being the atomic unit of (Shannon) information resource).

The latter leads to the cl-ps and co-ps mode network technologies.  Since we must have a connection in order to be able to deterministically manage resource we will only discuss the co-ps mode further (noting that by providing a parent connection the child co-ps mode traffic units can take various short cuts on their labelling vs their cl-ps mode cousins, specifically:  omit SA label, omit PID label (if constant client), reduce scope of DA label to link-unique rather than network-unique].  Here, a link-unique forwarding label (==DA proxy) now needs to be explicitly provided in each traffic unit and the traffic unit duration can be of a variable number of bits...so the resource required may not be known a priori of the arrival (at some variable epoch) of the traffic unit [Aside=> ATM fixed the number of bits in the traffic unit in order to attempt to provide some further determinism of resource demanded...and this has key implications wrt hierarchy, ie one cannot have 'self-nesting' in ATM, ie ATMoverATM...a critical observation that we come back to].

Now these factors on how we carve-up/label a time resource give rise to some key arch behaviours and differences between the modes...for example:
A	One is forced to have proper (single-source) connections in the co-cs mode....not necessarily true for the co-ps mode
B	One is forced to take the MP/CP logically OOB in the co-cs mode..... not necessarily true for the co-ps mode
C	Transparency (which is THE key client service property of a transport network) is always provided in the co-cs mode (ie all client symbols treated equally wrt forwarding importance irrespective of the ultimate TOS nature of the message/file/stream application, which must always be present in all networking cases).... not necessarily true for the co-ps mode
D	A key corollary of transparency is that there is no such thing as 'QoS classes' in a connection of the co-cs mode (which a very good thing for a transport network).... not necessarily true for the co-ps mode
E	Crucially (as we will see shortly) one cannot create hierarchy by 'self-nesting' traffic units of the co-cs mode, ie SDH VC4overVC4 is obviously not possible.....one can however 'self-nest' variable length generically structured traffic units of the co-ps mode (ATM being the exception as noted earlier due to the fixed traffic unit resource size).  


Now the PDH form of the co-cs mode was based on layer networks which could have independent clocks at each layer (within certain ranges).  The problem with this however is that one has to demultiplex the whole stack up to the highest layer of interest as one could not extract this easily/directly from some lower level aggregate.  SDH attempted to address this by providing much tighter allowed clock ranges over fewer layer networks.

However, these is still a major weakness here in SDH related to point E above which I will now explain...

In all networking scenarios there is always a:
-	TOS layer network like IP.....this interfaces directly with external message/file/stream applications) and a
-	BOS layer network present....this modulates an EM wave in either metallic/optical/radio media as this is the means to transfer information, ultimately sourced from the TOS message/file/stream applications, over large geographic distance.

A key measure of efficacy in networking (==cost) is the layer network distance TOS to BOS, ie how many layer networks do we have to create/configure/manage?....we need to reduce this to the smallest number possible (the answer is not one of course ;-)).  

Now consider the nature of the traditional PDH/SDH hierarchies and the fact that when not dealing with a TOS public network the key service one provides is the transparent carriage of the layer network of party M over a layer network of party N...this is a client/server relationship.  This means that party N has to carry the traffic units (ie whole bit-stream comprising DP/MP/CP) of the layer network of party M in a completely transparent manner.....so the payload area of the DP traffic units of the layer network of party N must fully contain al the DP/CP/MP traffic units of the layer network of party M.

But now what happens when party N wants its traffic units transparently carried over the layer network of some other party, O say? This means we have to create a even lower layer network to transparently carry of the DP/CP/MP traffic units of party N.  We can recurse this argument for carrying the traffic units of party O over an even lower layer network belonging to party P, etc, etc. 

What we end up doing is a creating a never-ending hierarchy of formally standardised layer networks, ie in theory an unbounded TOS to BOS layer network distance.  This is obviously not a great idea.

The current OTN just replicates the PDH/SDH hierarchy ideas.  What we really need is to recognise the above problem (ie we can't keep creating formal hierarchy just to carry some arbitrary defined layer network X over some further arbitrary defined layer network Y, etc) and move to the notion of a generic 'digital wrapper' framing structure for the traffic units of a true BOS co-cs mode layer network....which is in many ways looks like the co-ps mode, though we need the key arch behaviours I noted earlier for our BOS transport layer network, especially the notion of transparency.

regards, Neil


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Kireeti Kompella
> Sent: 12 December 2011 21:38
> To: Julien Meuric
> Cc: CCAMP
> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)
> 
> Hi Julien,
> 
> On Dec 6, 2011, at 7:31 , Julien Meuric wrote:
> 
> > Hi John, hi Lou.
> >
> > On the one hand, SONET/SDH and OTN are close: it is highly tempting to
> > prolong control of the former to the latter. Nevertheless, the GMPLS
> > deployments on SONET/SDH I am aware of only control high order
> > containers (i.e. SDH VC-4/VC-4-nc or SONET STS-1/STS-1-nc). In that
> > context, I do not think we can easily generalized protocol extensions
> > from an almost single-stage control to a highly multi-stage control.
> 
> Are you saying that OTN can be considered "highly multi-stage"?
> (asking, for my edification)
> 
> > On the other hand, it seems that PSC-1 to PSC-4 have not been
> > implemented much. Reasons behind are only guesses. Mine is that
> > upgrading implementations and deployments of MPLS-TE was not worth the
> > pain with respect to the added value of moving to the GMPLS flavor of
> > IGPs and RSVP-TE (especially for packet-only operations). Whatever the
> > actual reason for having so few implementations, PSC-n are part of the
> > original GMPLS specification.
> 
> I believe the primary reason is that in packet networks, hierarchy is
> primarily used for control plane scale.  In practice, this hierarchy was
> achieved as LDP over RSVP (not RSVP over RSVP, where one might have
> considered PSC levels); the current trend is LDP or RSVP over BGP.
> (Perhaps we should signal "labeled BGP" as PSC-n (n>1) using the BGP TE
> attribute!)
> 
> > Let me quote the section about PSC in RFC 4202: "The various levels of
> > PSC establish a hierarchy of LSPs tunneled within LSPs." This really
> > looks like what we are doing in OTN. Yes, the discrete nature of the
> > technology will introduce one more information into the SC field, but
> > doing otherwise would depreciate existing GMPLS specification.
> 
> Agree completely with you.  If the thinking behind the PSC levels from
> one of the original authors is of any interest, here it is:
> 
> For packet networks, there is clearly no pre-assigned bandwidth for PSC
> levels.  The intent was purely to control hierarchy; one was allowed to
> tunnel PSC-1 over PSC-2 ... over TDM over lambda over fiber.  One could
> (should, would) not tunnel fiber over lambda, or lambda over TDM (or TDM
> over packet, but then, MPLS is rife with layer violations.)  Likewise,
> an attempt to tunnel PSC 2 over PSC 1 was to be disallowed (or flagged
> for management intervention).
> 
> One could have considering defining levels of TDM as well, but (a) SDH
> was beyond me; (b) the standardization atmosphere around SDH was
> extremely charged; (c) my eyes would glaze over whenever SUKLM was
> mentioned.  Could one really assign SC TDM levels to PDH/SDH that
> captured the allowed hierarchy?
> 
> With ODU, I believe that one can simply assign numbers to levels such
> that the tunneling hierarchy is adequately captured.  I believe (but am
> not completely sure, as people here are amazingly innovative) that one
> cannot tunnel ODU5 over ODU0.  If that is of value, then there should be
> multiple TDM levels (or perhaps, ODU levels, between TDM and lambda).
> BTW, these levels have nothing to do with actual bandwidth.
> 
> > Furthermore, RFC 4203 says: "When the Switching Capability field is
> TDM,
> > the Switching Capability specific information field includes Minimum
> LSP
> > Bandwidth..." In other words, even if not included in the SC field so
> > far, one cannot really say that a value per ODUk layer would overload
> > the ISCD definition.
> >
> > Thus, we have legacy vs. depreciation:
> 
> Rather, I would say, think utility -- if it is useful to have multiple
> SC levels to capture the ODUk hierarchy, please do so.  You will not
> escape putting bandwidth somewhere (as I understand, there are multiple
> bandwidths for ODU2, and one has to be careful with suffixes and decimal
> places), probably in the ISCD.
> 
> One point of consideration is ODUflex -- where does it fit in the
> hierarchy?  How does one (if at all) assign an SC value to ODUflex?
> 
> > my understanding of IETF work is
> > to put emphasis on consistency and avoid defining new solutions when
> > they already exist, even if not absolutely optimized (we are not
> > building G.709 control from scratch).
> 
> Clearly, one can solve the problem in multiple ways and in multiple
> TLVs, including rolling an entirely new one.
> 
> > My 2 cents,
> 
> ditto
> 
> Kireeti.
> 
> > Julien
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp