Subject: RE: [IP-Optical] GMPLS - Hierarchies

From: [email-masked]
Date: Fri, 8 Dec 2000 11:37:34 -0000

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

---

From: "John Strand" <[email-masked]>
Date: Fri, 8 Dec 2000 08:55:20 -0500

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

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Friday, December 08, 2000 6:38 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [IP-Optical] GMPLS - Hierarchies

	Hi Juergen,

	Neil 

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

---

From: "Manohar Ellanti" <[email-masked]>
Date: Mon, 11 Dec 2000 06:34:20 -0800

Hi! John,

If you remember, we had a mail exchange on the OIF mailing list regarding
metro and core subnetwork interface and the signaling at this interface.

I think horizontal dependency and vertical dependency interms of
administrative domains might be required. Horizontal dependency could be
provider-to-provider kind of dependency to support customer circuit/service
end-to-end or it could be subnetwork-to-subnetwork . Vertical dependency
could be virtual network providers using perhaps MPLS backbone or TDM
backbone and providing fine grained bandwidth pipes in the case of packet
backbone or fixed/hierarchical bandwidth in the case of TDB.

Carrier-to-carrier peering much like IX and LEC access arrangements or
ISP-ISP peering might be required at the metro-long-haul hand-off points or
at carrier-to-carrier peering points.

 I am inclined  to think that provider-to-provider  interface (or  even in a
single administrative domain with  multiple subnets with different vendor
equipment or technology specifics)  right now requires more physical level
interworking engineering aspects to be resolved before control and
management plane interworking is to evolve. Issues such synchronization ,
signal hand-off, overhead bytes interworking etc may need to be worked out.
Packet based backbone interworking probably is much easier to understand
with multiple provider concept embedded in hierarchies, the same is not as
easily   understood with GMPLS applied to metro-long haul  or
carrier-to-carrier peering..

Manohar N Ellanti

----- Original Message -----
From: "John Strand" <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 08, 2000 5:55 AM
Subject: RE: [IP-Optical] GMPLS - Hierarchies