RE: GMPLS questions

["Vishal Sharma" <vsharma87@yahoo.com>]

Hi Giora,

I'll take a first stab at clarifying some of your doubts. I am sure others
will expand on
what I say.

Please see some responses below.

Thanks,
-Vishal

>-----Original Message-----
>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
>Behalf Of Giora Unger
>Sent: Monday, July 16, 2001 7:45 AM
>To: 'ccamp@ops.ietf.org'
>Cc: 'tnadeau@cisco.com'
>Subject: GMPLS questions
>
>
>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 abstract node will be able to represent an individual lambda if
each lambda is explicitly identified as an "interface" in the routing
protocol. For example, with an IP address (which would be wasteful)
or using router ID and unnumbered links (possibly as described in draft
http://search.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-unnum-01.txt;
which would help to conserve IP addresses).

If you are using link bundling, however, it may be more difficult to
force the selection of a particular wavelength at each hop, since the
choice of which wavelength to use would be a local decision. Actually,
even in this case, perhaps the label set can be used to restrict
the choice of the wavelength at each hop in the following way.
The first node (or central entity) picks the desired wavelength
and encodes it into the label set (which would be a singleton in
this case). At each subsequent hop, when making a local wavelength
selection decision, the node would ensure that it honored the
restrictions in the label set. This would guarantee that each
node picked the same wavelength for the lightpath.

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

I am not entirely sure what the above sentence means. Perhaps it alludes
to the fact that the abstract nodes are deleted from the list in the
explicit route as the setup message progresses towards the destination.
Or it may refer to the fact that in some cases an abstract node may
have to be expanded (by the node preceding the abstract node or by the
first node in the abstract node) to determine the exact sequence of nodes
that
the message is to pass through.

In any case, however, if the exact sequence of LSRs that the lightpath
is to pass through is known to the central entity, then it should be
possible to define an explicit route that is obeyed all along the
being-established path (in the sense that the message will pass through
the exact sequence of nodes specified; whether it will use the same
wavelength
at each hop may be determined either with the label set or bundling
considerations).

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

Yes, the "set" may contain a single element.

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

If the LSRs in question have no wavelength conversion capabilities then
simply selecting the desired wavelength and putting it in the label set
at the starting LSR will force the selection of the same wavelength
at all hops along the path (or the rejection of the lightpath, if
that wavelength is unavailable).

If, however, the intermediate nodes are
capable of wavlength conversion, then it is possible that a wavelength
conversion capable intermediate node may select a different outgoing
wavelength if the desired wavelength is unavailable but a different
one is available, and possibily drop the label set completely or
leave it unchanged, or change it to the outgoing wavelength
that it selected (depending on the implementation).
I am not sure off hand how one would force the choice of a specific
wavelength in that case.

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

Not sure what you mean here. Do you mean you still want to use
RSVP-TE or CR-LDP for path setup, but you want the messages to
emanate from the central entity as opposed to the head end LSR?
If so, you could, technically, simply embed the specific protocol
messages into whatever protocol the central entity uses to "talk"
to each LSR along the lightpath, and let the LSR interpret
those protocol messages as it would if they had been received on
an interface connected to an upstream LSR along that lightpath.

Another option would be for the central entity to issue a "setup"
command to the head end LSR, together with the explicit route (and
wavelength chosen), and let the head end initiate the ligthpath setup.


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

Don't think unidirectional lightpaths should be a problem.

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


Not really, except that the GMPLS switches wouldn't be operating in
a truly distributed way, so that you may not derive some of the benefits
that come from doing that. Also, you'd have to worry about the reliability
of the central entity and of its communication path to the individual
LSRs in your network.