The MPLS WG Archive

[Papadimitriou Dimitri <Dimitri.Papadimitriou@alcatel.be>]

Hi,

Please check the document draft-bala-mpls-optical-uni-signaling-00.txt
This draft reflects ongoing work at the Optical Interworking Forum
(OIF) and the Optical Domain Service Interconnect (ODSI) coalition
on the optical UNI [2]. (dixit)

In this draft you will find that:

Connection ID is explicitly needed in
Create response (specified since assigned by the network)
Delete request/response
Modify request/response
Status request/response
Notification message

Within the Create request the connection ID is unspecified

You will find within this draft the definition of lightpath ID (dixit)
Lightpath ID: A network-wide unique identifier for a lightpath.
This identifier is assigned by the optical network. It consists
of the IP address of an OXC along with a locally unique index.

Hope this helps you.

Regards,

Dimitri.

Fong Liaw wrote:

> Guangzhi
>
> I was not in the Maui meeting but what was
> advocated (by carrier group members) and agreed
> is that the signaling protocol MUST carry a
> "network assigned" ID as lightpath identifier.
>
> I completely agree with you that the Session
> object would serve the purpose at UNI, but OIF
> carrier group apparently think otherwise.
> My proposal in last email is a compromise.
>
> The MUST part applies only after it is assigned,
> most likely by Resv Message from network->user and in
> Path message from network->user (i.e. first hop network
> node).  We can go though the messages one by one to
> see which one really need to carry the connection_ID,
> but from what I heard, only ACK and Srefresh can be
> exempted from it.
>
> I would rather we don't have this in UNI ...
> So if you can convince your OIF carrier group
> representative to take it out, most of us would
> have no problem.
>
> George was in Maui OIF meeting, maybe he can tell
> us what's the situation there.
>
> -Fong
>
> >  -----Original Message-----
> >  From: Guangzhi Li [mailto:gli@research.att.com]
> >  Sent: Thursday, November 30, 2000 11:59 AM
> >  To: Fong Liaw
> >  Cc: 'Diego Caviglia'; mpls@UU.NET
> >  Subject: Re: draft-yu-mpls-rsvp-oif-uni-00
> >
> >
> >  Fong:
> >
> >  From signaling point of view, let's clarify something first:
> >  (1) who generate the "Connection_ID" ? The first-hop-router in the
> >  network, right.
> >  (2) Suppose that I am a user node and I want to setup a lightpath. I
> >  send out a lightpath request throught UNI. Then the first-hop-router
> >  will try to establish the lightpath.
> >  (3) When will I get the connection_ID from the network?
> >  (4) You said that a user node MUST carry the object in every
> >  subsequent
> >  RSVP messages it generates. You mean "refresh messages, teardown
> >  messages, or update messages" ?
> >  (5) If my understanding is correct, why should a user node bother
> >  "Connection_ID"?
> >  (Connection_ID = AS number+source address+local_id). Any ID
> >  simpler will
> >  work between UNI.
> >
> >  Please give me more explanation. Thanks,
> >
> >  -- Guangzhi
> >
> >
> >
> >  Fong Liaw wrote:
> >
> >  > Hi, Diego
> >  >
> >  > The official name for ligthpath ID is now "Connection_ID".
> >  > We are still discussing (among authors) how this
> >  > object should be used and therefore where it should
> >  > show up in the messages.  Right now, we don't have
> >  > a clear definition of these from the requirement
> >  > but this will hopefully be resolved between the
> >  > carrier group in OIF and the signaling group authors soon.
> >  >
> >  > Right now our proposal is the following:
> >  >
> >  > "The Connection_ID object will be an optional
> >  > object in all RSVP messages. However, once a
> >  > Connection_ID is assigned by the network,
> >  > a user node MUST carry the object in every
> >  > subsequent RSVP message it generates."
> >  >
> >  > This phrase gives network the freedom of generating
> >  > or not generating a Connection_ID, and if they do
> >  > generate one, a user node will play it back to
> >  > the network.  A connection is still identified by
> >  > RSVP Session object, at the UNI.
> >  >
> >  > -Fong
> >  >
> >  > >  -----Original Message-----
> >  > >  From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com]
> >  > >  Sent: Thursday, November 30, 2000 5:54 AM
> >  > >  To: mpls@UU.NET
> >  > >  Subject: draft-yu-mpls-rsvp-oif-uni-00
> >  > >
> >  > >
> >  > >
> >  > >
> >  > >  Fong,
> >  > >                 I've seen that w.r.t. the OIF version of this
> >  > >  draft a Lightpath
> >  > >  ID object is introduced but in the message definition I
> >  > >  can't find it.
> >  > >
> >  > >  If it is not a mistake, could someone explain in wich
> >  > >  message Lightpath ID must
> >  > >  be inserted?
> >  > >
> >  > >  Regards Diego.
> >  > >
> >  > >
> >

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+322-3434361
tel;work:+323-2408491
x-mozilla-html:FALSE
org:Alcatel;Corporate Research Center
adr:;;Francis Wellesplein, 1;Antwerpen;Antwerpen;B-2018;Belgium
version:2.1
email;internet:Dimitri.Papadimitriou@alcatel.be
title:Telecom R&D Engineer
fn:Papadimitriou Dimitri
end:vcard