The MPLS WG Archive

["John Strand" <jls@research.att.com>]

Hi Juergen et al,
I'd like to support Juergen's emphasis on the importance of dealing with
heterogeneous subnets. This is going to be an important practical
issue for many carriers in the immediate future because of the need to interwork
between metro and core optical subnets, which may be from multiple vendors and
which will necessarily have proprietary (pre-standards) control planes. Note 
also the recent OIF submission by Corvis that recommended a subnet approach when interworking with
all-optical "clouds". I think this area ought to be an important focus of
standards work.

John

John Strand  <==== NOTE NEW ADDRESS & PHONE
AT&T
Lightwave Networks Research Dept.
200 Laurel Ave., Room A5-1D06
Middletown, NJ 07748
(732)420-9036
jls@research.att.com 

-----Original Message-----
From: ip-optical-admin@lists.bell-labs.com
[mailto:ip-optical-admin@lists.bell-labs.com]On Behalf Of
neil.2.harrison@bt.com
Sent: Friday, December 08, 2000 6:38 AM
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


	Hi Juergen,

> We can set-up a connection using signaling or by configuration hop by hop
> via the TMN. MPLS uses the first approach, but basically you could also
> configure a MPLS LSP hop by hop via the TMN. In SDH/Sonet and the OTN we
> have today only the TMN approach and I don't expect that all networks and
> users will switch to signaling on day one. So we have to cope with a mixed
> enviroment, some networks use signaling some not. In this case only
> sub-network connections of the overall trail are set-up via the
> control-plane using signaling. This is what I was concerned about in my
> first mail and what should be covered by GMPLS.
	NH=> OK.  So your key point is the 1/2 TMN + 1/2 Control-Plane
provisioning of LSPs.  I think this is a valid concern.
	We have the same situation today with ATM, ie some operators will
run PNNI-based S-PVCs to an international gateway, others will run TMN
H-PVCs to their side of the gateway, and there will be an end-end VP (say)
trail running across the 2 domains.  One ends up with a sort of back-back
UNI solution that creates a resilience pinch-point.

	So, just from an evolutionary perspective, then the situation that
you are raising is a valid practical one, and operators will need to put
processes in place to handle it just like they do today.

	One issue to watch is this......what information needs to be
conveyed between the 2 ends of the trails that are in the different domains?
For example, how do we ensure correct connectivity both at set-up time and
subsequently?  I believe the LMP ID gives one possible solution for within a
single domain (I would need to review exactly what is in there but I do
recall seeing something about this), but this will not (?) be appropriate to
the case you are describing I guess.  The usual technique to ensure correct
connectivity is to send a periodic Trail Termination Source Identifier
(TTSI), in the user-plane, from the source end of the trail to the sink end
of the trail.  Indeed, I am proposing just such a mechanism for the
user-plane CV (Connectivity Verification) OAM packet of MPLS to detect all
the types of misconnectivity that can occur, eg LSP breaks (below or within
MPLS fabric), swapped LSPs, mismerged LSPs.  Ideally the sink end of the
trail/LSP needs automatically configuring with the expected TTSI....say
through the LSP signalling mechanism at LSP set-up time.  However, for the
case you are raising this would not be possible and would need to be done
via some other means, eg manual entry or 'self-learnt' from the initial TTSI
seen in user-plane at t=0 when the LSP is 1st brought up.

	Neil 



_______________________________________________
IP-Optical mailing list
IP-Optical@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/ip-optical