The MPLS WG Archive

[Yangguang Xu <xuyg@lucent.com>]

Dimitri,

You may notice that some details of draft-bala-mpls-optical-uni-signaling-00.txt
need to be updated to reflect the "upcoming" latest OIF UNI signaling spec.
Lightpath ID is one example.

Yangguang

Papadimitriou Dimitri wrote:
> 
> 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.
> > >  > >
> > >  > >
> > >