The MPLS WG Archive

[Fong Liaw <FLiaw@zaffire.com>]

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