GMPLS questions

[Giora Unger <giora@orikanetworks.com>]

Hi everybody,

It's going to be a long one. Sorry, but I couldn't contain everything I
don't understand in a shorter message :-)

After reading the GMPLS architecture draft, there are still some issues
regarding GMPLS that I'd like to clarify.
I'll start with the background, such that you'll have better understanding
of my questions:
We're working in the domain of wavelength switching networks (LSC interfaces
in the GMPLS terminology). 

Lets examine (briefly) such a network; 
Multiple optical switches are distributed in the network. They are GMPLS
LSRs, which contain LSC interfaces, capable of switching between an incoming
lambda and an outgoing lambda.
Those LSRs can be manufactured by various vendors, and the only thing one
can be sure about them is the fact that they claim to support GMPLS.
We'd like to build a system in which a centralized entity decides which
switching operations are to be performed in each of those LSRs, and further
would see to it that those switching operations were actually executed.
We're well aware that GMPLS is distributed in nature, and that we're taking
it to the centralized direction. However, we'd like to verify that we're not
missing anything.

The questions:

1. Given such an LSR, can we FORCE it to switch between a two specific
lambdas ? Two mechanisms described in the document imply that it's possible,
but both are not clear-cut:

a. "Explicit Route" - in section 9.13. As far as I understood, if we define
the Explicit Route with a list of "strict Simple Abstract Nodes", and in
case that the "abstract node" concept can also express a specific lambda, we
can achieve the above.
Am I correct ? How is the Label Restriction mechanism (below) related to
this mechanism ?

The main doubt was raised due the following line (in 9.13):
"Note also that an explicit route is altered by intermediate LSRs during its
progression towards the destination."
Does it mean we can't define an Explicit Route that would be obeyed all
along the -being-established path ?

b. "Label Restriction by the Upstream Node" - in section 9.8 it is implied
that such a restriction is possible to a set of lambdas. Can "set" be also
interpreted as a single lambda to be forced ? 
Additionally - in the last paragraph of section 9.8, it's written:
"A Label Set may be present across multiple hops. In this case each node
generates its own outgoing Label Set, possibly based on the incoming Label
Set and the node's hardware capabilities."
Hence, is it possible to force specific lambdas in all the LSRs along the
path, according to decisions that are not subject to manipulations by the
LSR along the way ?


2. Lets assume that our centralized entity decided to create a lightpath
between two Edge Nodes, A and B. Must the GMPLS messages actually creating
the LSP be sent from A along the actual path, or can that centralized entity
function as the sender ?
In other words - can the messages for actual LSP creation be sent not along
the physical path of the LSP ?

3. We understood that there is no problem with having uni-directional LSPs
also in GMPLS wavelength switching environments. We'd like to verify we
didn't miss anything.

4. Disconnecting an LSP - we found in the RSVP-TE specification a "Time To
Live" and a message to disconnect an LSP. However, we didn't find such a
mechanism in CR-LDP.
Which mechanism should be employed in order to disconnect an LSP in GMPLS ?

5. Do you see any flaws in the general scheme I described above ? That is -
in utilizing GMPLS optical switches (LSRs) as relatively dumb entities which
practically obey the commands of a centralized entity.


Thanks a lot and sorry for the flood of questions ;-)

-------------------------------------------
Giora Unger
Orika Optical Networks Ltd.
www.orikanetworks.com
Phone: +972-3-6091665 ext. 29
Fax:     +972-3-6091667
E-mail: giora@orikanetworks.com 
-------------------------------------------