The MPLS WG Archive

[neil.2.harrison@bt.com]

Taner....you are referring to the architectural concept of 'layered
networks', which is one facet of the larger discipline of functional
modelling of networks.  That is, a link connection of a client trail (which
is 1 hop in the client trail) = a server layer trail.  LSPs create layered
networks (of theoretically arbitrary nested depth), and it is something the
IETF are going to have to get to grips with if MPLS is going to progress
beyond an intra-domain 'IP accessory' and have any properly engineered
future.  This does not seem well understood by many it seems, and it has
some very important consequences that cannot be ignored....especially wrt
the functionality that must be applied at trail termination points and the
server->client adaptation mappings.  Getting to grips with these concepts is
critical as one moves the focus from intra-domain to inter-domain.

You may have seen some mails from me in the past that gave some warnings on
the need for more architectural rigour in this area....such as:
-	since client layer links = server layer trail terminations,
addressing across nested layer networks cannot be congruent (this is an
important issue for the Optical Transport Network and its many
clients....here the concept is generalised MPLS);
-	PHP......makes the trail termination point of an LSP ill-defined for
server->client functional handling, eg this has several OAM consequences;
-	EXP codepoints......if one is carrying a higher layer LSP between 2
private MPLS networks say and using one or more public MPLS networks for
transit (ie on lower layer LSPs) than one cannot assume some consistent EXP
relationships across all the layer networks;  In particular, one must have
the ability to convey the private domain's client LSP EXP codepoints
transparently and independently of any use of EXP codepoints in lower layer
server LSPs;
-	TTL....similar to above, and again TTL is only relevant to layer it
is generated in.  In particular one should never guess a latent number of
server layer hops (for example, one consequence is that on server layer LSP
restoration the number of server layer hops will generally change, and this
should be of no consequence to the client layer LSP....since from its
perspective, its still just 1 client layer hop, ie a link connection).

For further information see ITU Rec G.805.  There are also some good text
references on functional modelling, in particular this one that was
co-authored by a BT colleague of mine Andy Reid and Mike Sexton (of
Alcatel):
Broadband Networking, Artech House; ISBN: 0890065780.

Until we all accept and get a better understanding of the architectural
nature of layered networks, MPLS will flounder as soon as its moves its
focus to inter-domain....and without such a move it offers very little real
benefit since it becomes architecturally non-scalable.

Neil
> -----Original Message-----
> From:	Taner OKUMUS [SMTP:iokumus@mailbox.syr.edu]
> Sent:	Monday, November 27, 2000 3:33 AM
> To:	mpls
> Subject:	interdomain LSP setup 
> 
> I have a general question.
> I understand that LSP setup in an autonomous domain is well-defined. Owner
> of the domain can setup end-to-end ( ingress to egress) LSPs inside the
> domain.
> How does interdomain transfers handled? Suppose I want to setup an LSP
> passing through 2 different ASs and ends up in some subnets in the second
> domain. Each domain uses LDP or RSVP to distribute the label between
> ingress
> and egress of that domain. Then each domain can setup LSPs in their
> domain.
> What happens between the egress of the first domain and the ingress of the
> second domain? To put inanother way, does LSPs end-to-end in an AS or are
> they end-to-end in the system ( meaning from one ingress of a domain to
> egress of another domain) ?
> 
> 
> Taner