The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Jun> msg00134



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Ships in the Night operation on ATM-LSRs

  • From: David Charlap <david.charlap@marconi.com>
  • Date: Mon, 24 Jun 2002 11:00:44 -0400
  • User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a) Gecko/20020613

Chetan Pinto wrote:
> There are ATM LSRs that support Ships in the Night operation
> on ATM interfaces. Thus these ATM interfaces are also LC-ATM interfaces
> 
> The vpi/vci range on an ATM interface is shared between MPLS and other
> applications and each application is aware of the range available to it.
> 
> The label [vpi/vci] range in case of LDP is
> negotiated during the LDP initializaion phase between
> two LDP peers on the ATM link connecting the two.
> 
> As far as the LDP session state machine is concerned
> negotiation of parameters is restricted to the Initialization phase.
> 
> Considering a case wherein one of the ATM applications relinquishes
> it's label range [i.e. the user no longer needs to use that
> application]. The user then has a choice of lending the freed range
> to another ATM application. When doing so, MPLS could also be one of
> those candidate applications. At the same time it is assumed that a
> similar action  is taking place on the other end of the ATM link.

This presumes that the label space is partitioned.  This isn't really a 
requirement.

Every MPLS protocol can advertise the full label range without fear of 
the two stepping on each other.  The neighbor router will always know 
what labels are in-use, since ATM labels (VCIDs) are always 
per-interface, so you won't ever see one label assigned to two protocols.

Label space partitioning for SIN is for administrative purposes, not 
technical ones.  Similarly for anybody who wants to partition the label 
space among several MPLS protocols.  Given this, it is unlikely that 
this space will re-partition very often.  If the overhead of 
repartitioning is unacceptible, I'd look at the LDP graceful restart 
draft (draft-ietf-mpls-ldp-restart-02.txt and consider using that to 
minimize the impact of restarting LDP, rather than changing LDP.

-- David