Subject: RE: MPLS tunneled in IP

From: [email-masked]
Date: Tue, 25 Sep 2001 09:43:31 +0100

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
>

---

From: [email-masked]
Date: Tue, 25 Sep 2001 10:20:08 +0100

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'; [email-masked]'
> 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 
> 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

---

From: "Metz, Eduard" <[email-masked]>
Date: Tue, 25 Sep 2001 11:43:52 +0200

> eg IP over MPLS and SDH over OTN make sense, SDH over IP does 
> not.  

IMHO "unconventional" layering (such as SDH over IP) could make a lot of
sense e.g. for providers with an IP-only infrastructure that want to offer
"traditional" bandwidth services in a limited fashion. The PWE3 group is
centered around this thought ...

cheers,
	Eduard

---

From: [email-masked]
Date: Tue, 25 Sep 2001 11:27:29 +0100

> centered around this thought ...
Eduard, whilst I agree it might (?) make sense for the *providers* I am not
so sure about the *users*.
regards, Neil

---

From: "Metz, Eduard" <[email-masked]>
Date: Tue, 25 Sep 2001 14:11:38 +0200

> specifying

It should not matter to the users. If a provider is able to provide an STM-1
circuit that satifies customer requirements using pigeons it should be
alright. Ofcourse there is user/customer perception which in some cases
prohibits certain implementations (or the other way around where customers
demand certain technology just because it is in fashion at the time). But
that is a "marketing" issue rather than a technical one ...

From a technical point-of-view it shouldn't matter how the service is
implemented, as long as it meets the service requirements of the users.

cheers,
	Eduard