RE: New draft

[Hang Liu <hliu@tellium.com>]

Hi.

I think what Adrian said makes sense. With Suggested Label, the resource can
be allocated in parallel along the path. The local operation within the node
to set up a connection can be divided into three phases.
1) Admission control. The NE checks whether resource is available after
receiving the connection request, e.g. RSVP PATH message
2) Reservation. Reserving the resource in the NE, e.g. wavelength or port
3) Allocation or commitment. Setting up the real connection in the NE, e.g.
cross-connect.

With Suggested Label, a node can do admission control and reservation (hope
that the delay for this process is not that large). It then passes the RSVP
PATH with necessary message processing to the downstream node with Suggested
Label. After the PATH message is forwarded to the downstream node, the node
can start setting up the connection within it. In this sense, the connection
setup can be done parallel. Of course, there is also some security issue. We
don't want to have data transmission over the path, for example, in the case
of UNI applications before the destination client agrees to accept the
connection. ResvConf can be used for this security. 

In independent LSP control, each LSR may make an independent decision to
assign a label to a FEC and to advertise the assignment to its neighbors.
This is more similar to conventional IP routing. In optical networks, GMPLS
is used to set up a circuit. Each node sets up the cross connect from an
incoming port/channel (label) to an outgoing port/channel (label) according
to the request in the signaling. One way to speed up this path provisioning
process is that an intermediate node passes the PATH message to the next hop
without doing admission control and reservation. After the PATH message is
passed to the next hop with necessary message processing  (e.g. ERO and HOP
objects encoding, etc), the node can further process the PATH message,
negotiating and assigning port/channel/label with its neighbors, setting up
the cross connect internally after negotiation is down. However this
requires extra signaling between neighbors. Not sure it is worth.

Regards

Hang
Tellium, Inc

-----Original Message-----
From: Rajaraman B [mailto:brajaram@npd.hcltech.com]
Sent: Thursday, February 14, 2002 10:01 AM
To: Adrian Farrel
Cc: ccamp@ops.ietf.org
Subject: Re: New draft


Hi Adrian,
	In which draft they have give like that. I did not find this
sentence in 
GMPLS architecture draft. can you please the specfic draft?

	Another thing, I want to ask you is that why is Independent label 
provisioning not possible in optical network (that is, in GMPLS)? can you 
please explain that?

Regards,
Rajaraman. B

On Thursday 14 February 2002 8:04 pm, you wrote:
> No, I believe I am right.
>
> Section 4 explicitly says "That is to say, the nodes along a lightpath
will
> do their local resource allocation one by one."
>
> This is not a requirement in GMPLS.
>
> Exactly the process described with the PRAO object can already be achieved
> using Suggested Label.
>
> Adrian
> ----- Original Message -----
> From: "Rajaraman B" <brajaram@npd.hcltech.com>
> To: "Adrian Farrel" <afarrel@movaz.com>; <whui@mail.ustc.edu.cn>
> Cc: <ccamp@ops.ietf.org>
> Sent: Wednesday, February 13, 2002 1:54 AM
> Subject: Re: New draft
>
> > Hi,
> > I think Mr.Wang Hui has explained the Independent Label Provisioning
> > method explained in MPLS architecture (RFC-3031). But, in RSVP-TE and
> > CR-LDP, we use Ordered Label Provisioning method (started by egress
> > node).
> >
> > So, I think there is a difference in Wang-Hui draft and GMPLS-RSVP-TE-06
> > draft.
> >
> > Regards,
> > Rajaraman. B
> >
> > On Tuesday 12 February 2002 6:42 am, you wrote:
> > > Wang,
> > > Your draft seems to ignore Suggested Label which facilitates (with
> > > suitable implementation details) exactly the function you require.
> > > Regards,
> > > Adrian
> > > ----- Original Message -----
> > > From: "Wang Hui" <whui@mail.ustc.edu.cn>
> > > To: <ccamp@ops.ietf.org>
> > > Sent: Sunday, February 10, 2002 5:42 AM
> > > Subject: New draft
> > >
> > > > Hello all,
> > > >
> > > > A new draft named as "Add a 'parallel resource allocation style
> > > > object' to GMPLS signaling - RSVP-TE and CR-LDP"
> > > >
> > > > This draft suggests a new object implemented into GMPLS signaling
set
> > > > in order to provide fast LSP establishing speed.
> > > >
> > > > The URL is :
> > >
> > >
http://www.ietf.org/internet-drafts/draft-hwang-gmpls-signaling-paralle
> > >l-00 .txt
> > >
> > > > All are welcome to have a discussion over it.
> > > > Please send your comments to : whui@mail.ustc.edu.cn
> > > >
> > > > best regards,
> > > > Wang
> > > > --
> > > >  Wang Hui
> > > >  InfoNet Lab, USTC
> > > >  http://mail.ustc.edu.cn/~whui
> > > >  Tel: +86-551-3603634