The MPLS WG Archive

["Manohar Ellanti" <ellanti@home.com>]

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" <jls@research.att.com>
To: <neil.2.harrison@bt.com>; <Juergen.Heiles@icn.siemens.de>;
<jdrake@calient.net>; <mpls@UU.NET>
Cc: <ip-optical@lists.bell-labs.com>
Sent: Friday, December 08, 2000 5:55 AM
Subject: RE: [IP-Optical] GMPLS - Hierarchies


> 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
>