The MPLS WG Archive

[neil.2.harrison@bt.com]

Mail failures indicated...apologies if this is a repeat.
> -----Original Message-----
> From: Harrison,N,Neil,IKO1 R 
> Sent: 25 September 2001 09:47
> To: 'Mareline Sheldon'; 'giles'; 'kameswara.rao'
> Cc: 'Henry Bibb'; 'mpls@uu.net'
> Subject: RE: MPLS tunneled in IP
> 
> 
> Mary,
> 
> There is no easy answer to this well-known network design 
> problem I am afraid.
> 
> One can carry any client network link connection (ie between 
> nodes in the client layer) on any server layer trail (ie an 
> end-end trail in server layer).  This is indeed how one 
> constructs the topology of a client layer network....aka as 
> traffic engineering by some.  [See G.805 for some good 
> information on the client/server and partitioning layer 
> network architectural relationships]  It is a recursive 
> process that terminates at the duct layer network;  and the 
> duct network layer sets the bounds on the inherited disjoint 
> connectivity, and hence availability, of all supported client 
> layer networks....QoS metrics, like errors, simply get 
> inherited directly, and usually with some non-linear temporal 
> extensions (eg due framing aberrations or such), at each 
> server->client trail termination/adaptation function.
> 
> The problem arises when one allows unbounded and unspecified 
> (per instance) client/server layer relationships but one 
> still wants to define/assign some end-end QoS/availability 
> SLA for the (top) layer network trail that has to be met.  
> Clearly there is a potential performance impact each time one 
> goes up/down a layer stack, and if there are no constraints 
> on (i) what is allowed and (ii) how many times this can be 
> done, then there is now way to assure that the SLA for the 
> (top) layer network trail concerned can be met. 
> 
> {Aside - When a new layer network technology is defined in 
> the ITU there is usually some attempt made to specify a 
> global HRX (Hypothetical Reference Connection) with end-end 
> (per layer network trail concerned) metrics/objectives which 
> are then broken back into partitioned objectives for segments 
> of that HRX trail (eg per domain-like apportionments).  There 
> is also some attempt harmonise these metrics/objectives over 
> all layer network types......however, this process has never 
> been fully specified because it is too complex, eg there are 
> too many potential client/server nested combinations and the 
> metrics/objectives for layer network X (ATM VP say) cannot 
> always be easily harmonised with those for layer network Y 
> (SDH VC4 say).
> Further, with a cnls fabric, the linear HRX partitioning 
> cannot be done recursively within the layer.  This is not a 
> flaw or anything, its simply the design behaviour of cnls 
> networks.  This means one cannot easily specify partitioned 
> HRX objectives for IP.  This can usually (see Note) only be 
> done on an end-end basis, ie where the IP header is 
> generated/terminated (Note - the potential exception to this 
> is on a domain basis where traffic is forced through a single 
> point of interconnection).  co layer networks OTOH can be 
> partitioned wrt end-end HRX (trail) metric objcetives.}
> 
> So the only thing I can advise here is exercise care when 
> specifying specific client/server relationships since some 
> make more sense that others, eg IP over MPLS and SDH over OTN 
> make sense, SDH over IP does not.  And if you lease a given 
> trail connection at layer X from some service provider, you 
> might want to try and find out how that trail is supported 
> down to the duct in that service provider's 
> networks......because all you will see will be the top layer 
> trail and the specific (and number of) client/server 
> adaptations will be hidden.
> 
> regards, Neil
> 
> 
> 
> > > > Hi,
> > > >    What is the application of tunneling mpls over ip ? 
> Since LSP's
> > cannot be
> > > > established through a non-mpls domain and the egress 
> lsr's anyway
> > perform
> > > > the transformation from mpls->ip .
> > > > Kamesh.
> > >
> > > But with MPLS over IP (or over GRE) LSPs *can* be 
> > established through a
> > > non-mpls domain.  Use targetted LDP sessions ("extended 
> > discovery") or
> > > BGP to exchange labels and then tunnel MPLS packets in IP 
> > or GRE to get
> > > them from one device to the other...
> > 
> > This much is okay .. but if you are using IP then how do you 
> > ensure that
> > your TE specifications are met .. and if this is not ensured 
> > then the very
> > use of MPLS is challenged !
> > am i missing something ?
> > 
> > Mary
> > 
> > 
> > 
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> > 
>