The MPLS WG Archive

[neil.2.harrison@bt.com]

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
>