The MPLS WG Archive

[John Ellson <ellson@lucent.com>]

Nuno,

The service being provided by a switched network provider between two
UNIs is a Link with one or more Link-connections providing capacity.
Once a Link-Connection has been provided it can be considered
by the user as a fixed resource which can be used to provide larger
composite connections.

Internal to the provider's domain the Link, in general, may be further
partitioned into Link-Subnet-Link, and Subnets can be partitioned
into Subnet-Link-Subnet, so a Link as provided to a User may
infact consist of an arbitrarily long alternating sequence
of Link-Subnet and a terminating Link.  As a minimum, all Links
provided by a Switched network can be composed
into:  Link-Subnet-Link.
The end Links could reasonably be called Access Links, but they are
not fundamentally different from any other Link. 

External to the provider's domain, the Link may be just a part of an
even longer composite Link, for example if one provider is just handing
off to another provider.

This is all partitioning.  i.e. this is all at one network layer
without any terminations or adaptations.  

At the limit of Link partitioning, the link-connections of a single
link may be provided by one or more parallel trails in a server layer.
e.g. A Link comprised of 6 Link-Connections may have 4 Link-Connections
provided by one Trail and 2 provided by another.  i.e. the relationship
between a Link and a Trail is not, in general, 1:1.

So the relationship between a Link provided to a 
user, and a trail in some server layer, is highly indirect and
is rarely 1:1.  This is why it makes no sense to talk about
the technology of the server layer when requesting
a connection in a client layer. 

When we are talking about partitioning, we should be talking 
about SNPs (Subnetwork Points), not TTPs of CTPs.
In connection management we presume that SNPs are also
TTPs or CTPs in real equipment, but during the establishment of a
connection within one layer the details of multiplexing 
can be abstracted away by use of SNPs.

SNPs are aliases, that is they carry a different name for the
same object instance.  Thus CTPs and TTPs have a name based
on physical containment that allows an operator to find
the smallest-replaceable-units during maintenance.  SNPs
on the other hand, carry a name that is convenient to
connection-setup.  e.g. labels.   Since Subnets can be nested,
a single CTP or TTP instance can have many SNP aliases.  One
for each of the nested Subnets.

e.g. The TTP: Net1,NE3,Board6,TTP2  may have SNP aliases:
2076, 949-2076, and 732-949-2076 if we have a hierarchical 
namespace.   Its also possible, in principle, that the SNPs
have names that  are unrelated to each other.

An SNP is the shared point on the boundary of a Subnet that
is at the junction of a Subnet-Connection inside the
subnet, and a Link-Connection outside the Subnet.  In any
connection operation, the Link-Connections represent the
fixed resource and the Subnet-Connection the flexibility.
(This is not saying that Link-Connections are inflexible,
only that a Link-Connection is static during the operation
to form a longer connection.)



I hope this helps

John Ellson
  

 



Nuno Silva wrote:
> 
> Neil et all,
> 
>  Under the scope of G.805 (March 2000), do you think it makes sense to model
> an LSP as a Network Connection, composed by a concatenation of SNCs and LCs
> (if so, what would be the subnetwork connections, the link connections, the
> TTPs and CTPs), or as an IP trail?
> 
>  TTPs - are the IP interfaces/ports?
>  CTPs- are the labels?
>  LCs - are the connections/associations between 2 labels in two different
> LSRs?
>  SNCs- are the forwarding tables in the LSRs and LERs? (a connection between
> the TTP and CTP in the LER, or a connection between CTPs in the LSRs)?
> 
>  So the question is indeed, is the functional architecture defined in G.805
> applicable to the MPLS/MPlambaS worlds?
>  How does this cope with G.cls (connectionless) work?
> 
>  Thanx ahead. Nuno.
> 
> 
> Nuno Carvalho Silva
> PT Inovação, SGR
> 
> Phone: + 351 234 403 394
> Fax: + 351 234 424 160
> E-mail: nunos@ptinovacao.pt
> 
> > -----Original Message-----
> > From: neil.2.harrison@bt.com [SMTP:neil.2.harrison@bt.com]
> > Sent: Wednesday, December 06, 2000 10:07 PM
> > To:   Juergen.Heiles@icn.siemens.de; jdrake@calient.net; mpls@UU.NET
> > Cc:   ip-optical@lists.bell-labs.com
> > Subject:      RE: [IP-Optical] GMPLS - Hierarchies
> >
> > <snipped>
> >
> > > Furthermore a LSP -at least for circuit switching - doesn't have to
> > start
> > > and end at the trail termination where you extract your payload.
> >       NH=> I fudamentally disagree *if* we are adhering to functional
> > arch.
> > >  A LSP could be used only for a sub part of the overall connection, e.g.
> > a
> > > DS1 signal starts in a user domain with tradional TMN path setup or even
> > > manual connections, the DS1 comes to a operator which uses GMPLS for
> > path
> > > -setup (in this case a permanent connection set-up by himself as the
> > user
> > > doesn't support the UNI). The LSP starts in the middleof the overall DS1
> > > connection and no access to the paylaod of the DS1 is requried at that
> > > point.
> >       NH=> The DSI signal is 'an LSP' in its own right......it is, after
> > all, a clear layer network trail entity.  The fact that it may be served
> > (on
> > link connections, which are a partition of the end-end DS1 trail) by lower
> > layer "LSPs" (which could be a DS3, VC4, ODU, etc.......and which
> > themselves
> > are trails *but* only between their points of source/sink) is
> > academic.....the DS1 trail is completely unaware of this, and the layering
> > recursion of client_links=>server_trails can recurse many times.......its
> > stops at the duct network.
> >       Your example *must*, and indeed does, fit this.
> >       neil
> >
> > >
> >
> > _______________________________________________
> > IP-Optical mailing list
> > IP-Optical@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> 
> _______________________________________________
> IP-Optical mailing list
> IP-Optical@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/ip-optical