[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving right along ... Switching Type
I had read the routing drafts (as thet are referenced from the signaling
drafts), and was expressing confusion as a result.
The Switching Type values are very broad (each includes several possible
encapsulations, including NULL, of the LSP being created). What exactly
they include is not clear. For example I don't know where G.709 switching
would be included. In fact, even the names are a bit confusing, for example
"TDM Capable" -- I don't see what multiplexing has to do with switching
(one can switch among both multiplexed and non-multiplexed interfaces).
I assume "TDM Capable" means SONET/SDH and maybe PDH...
I have always thought that the LSP Encoding Type, along with the TSPEC,
was sufficient to indicate what was being setup (switched) and that how
that LSP was encapsulated on each link was a local issue. For example,
a packet LSP may be encapsulated in Ethernet, ATM, or FR on any given
link along its path, even switched in those forms over several hops, but
this is not an end-to-end concern. In fact, restricting the switching
type in this case would only artificially restrict the set of available
Similarly, I think that if one wants to set up an OC-48 RS transparent
LSP, it may be switched at some hop(s) over Lambda-Switch capable
links and at some hops over TDM Capable links or even Fiber Switch capable
links, and that is just fine. Why one would want to restrict this
is not clear.
John Drake wrote:
> I think part of the problem is that you also need to read the GMPLS routing
> There are also comments in your text.
> -----Original Message-----
> From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com]
> Sent: Monday, October 29, 2001 9:53 AM
> To: Kireeti Kompella
> Cc: email@example.com
> Subject: Re: Moving right along ... Switching Type
> In reviewing the GMPLS signaling drafts I have been unable to
> get a clear understanding of the need for and use of the Switching
> Type field in the Generalized Label Request object.
> JD: The Switching Type field is for handling the situation where there
> are multiple switching capabilities per interface (see section 6.4.6 of
> This appears to be an attempt to address LSP setup involving multiple
> layer networks, but it does not adequately address the issues involved.
> JD: Would you please provide some additional prose explaining your
> reasoning on this?
> That it "Indicates the type of switching that should be performed on a
> particular link." makes it seem to be a local concern, while others
> have indicated it is an end-to-end field. For example, George Swallow
> says "It is my understanding that for a given LSP it does not change,
> but is carried end-to-end and applies at all intermediate hops along
> the path."
> JD: I think George's interpretation is correct, and I don't think the
> other text you quoted contradicts George. If a given TE link supports
> multiple switching types, the node controlling that link needs to know
> what switching type a given LSP wants to use.
> As an end-to-end item I have trouble understanding how the originating node
> would determine how to set this (on what basis one determines what switching
> choice to make in all cases). In fact, I'm not sure why the originating
> node would care what type of switching is used as long as the LSP is
> to the egress faithfully.
> JD: The orgin node uses the switching capability information in the link
> database in its CSPF calculation to ensure that switching capability is
> along the path of the LSP.
> Ben Mack-Crane