[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-takacs-asym-bw-lsp-00.txt
Hi All
Igor has captured my understanding as well that the
situation we are concerned with is a GMPLS control plane being deployed to map
the capabilities from a management plane.
In terms of this requirement I see GMPLS control of
optical/tdm and GMPLS control of Ethernet being just as you say: The ingress
node knows the bandwidth for both directions.
Regards,
Don
Adrian and Dimitri,
When a GMPLS tunnel is setup, it is
setup for a reason. Let's say, management plane requests a tunnel
ingress node to setup a tunnel. The request may not (and normally does not)
contain an explicit path, but it definitely contains all bandwidth parameters,
because the tunnel was requested, as I siad, for a particular
reason (application, SLA, etc.). Also, how else you can ensure the fate
sharing other than computing a path on the ingress node taking in
consideration the bandwidth requirements for both directions?
So, yes, I'd
say that it is safe to assume that ingress node always knows about bandiwidth
in both directions.
I'd say even more. We have a strict requirement
from our customers that actively deploy our GMPLS CP, that a communication
between management and control plane should always hapen at one (ingress)
node.
Igor
PS It would be interesting to hear from providers on
this topic.
Dimitri.Papadimitriou@alcatel-lucent.be
wrote:
"Adrian
Farrel"
04/03/2007 00:35
Please respond to
"Adrian Farrel"
To: "Igor Bryskin" , Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: , "Don
Fedyk"
Subject: Re: I-D
ACTION:draft-takacs-asym-bw-lsp-00.txt
> 3. if a) is selected
there is no other choice than an upstream flowspec
in
> the Path
msg and a upstream tspec in the Resv message
That *does* raise an
interesting question. Namely, does the ingress know
the
bandwidth to
request? If it does then there is no need for a TSpec on the
Resv as the
reservation has already been made commensurate with the
FlowSpec
on
the Path.
-> if you do that you prevent the ingress-side to never
adapt resource
reservation to the traffic parameters of the egress (in
fact, it would
boil down to "single-sided" asymmetry
forever)
-> hence, initially you must satisfy at least condition
where flowspec
=< tspec, nevertheless, after the tspec may "increase"
and therefore
the flowspec may be adapted
If the ingress does
*not* know and needs to see a TSpec from the egress,
then we need
another Path exchange after the Resv in order to make the
actual
reservations. In that case it really would be a mess and not worth
trying to shoe-horn into a bidirectional LSP format.
-> this
is what i said also to don, the case where initially the ingress
is
completely unaware of what it can reserve is impossible without
major
protocol modifications
-> my partial conclusion, is that
a workable asym bw lsp doesn't elevate
the need for the general case, and
only provides apparent facilitation in
a corner case, whereas a technique
making use of association object would
prevent all this protocol
massaging, keep full backward compatibility, and
provide full
flexibility
A
It's here! Your new message!
Get new
email alerts with the free Yahoo!
Toolbar.