|
Hi,
As you might know, the NNI interoperability test at the
Supercomm 2002 has been cancelled.
But, you can still refer to the document
(oif2002.025) _just_ for your reference.
(It's under heavy discussion among the principal
members in the OIF.)
Soo-Hyun
----- Original Message -----
Sent: Thursday, April 11, 2002 5:34 AM
Subject: Re: UNI end-to-end sessions
Hi Sudheer, all,
I think the work is actually part of
the Supercomm NNI work effort
(there is no private NNI effort within OIF).
For folks involved with OIF
and Supercomm NNI, see OIF2002.025, Section
7.4, which clearly includes
the facility to transport UNI-specific
information (such as TNA) from
source UNI to destination UNI.
This
is not part of the IETF GMPLS documents yet. I view the GMPLS work
in IETF
as laying a foundation for using IP-based protocols. For
example, the OIF
and ITU-T may use these protocols to extend the
capability to support
UNI-based, and E-NNI-based signaling and routing.
In fact this is exactly
what was done for the UNI.
Zhi
FYI, I've also added oif-signal@oiforum.com to the cc:
list
Sudheer Dharanikota wrote:
>There has been some
effort in proposing a TLV to carry some of the
>UNI specific parameters
into NNI cloud. This was part of Private NNI
>at OIF. Once we sort
requirements out at OIF on NNI and UNI 2.0 front,
>we can go to the
details of this TLV.
>
>- sudheer
>
>Diego Caviglia
wrote:
>
>>Hi
Monica,
>>
I agree with you that there isn't a UNI end-to-end
>>session, but in
my understanding what Gino was asking is how to map UNI
>>information
that has end-to-end significance.
>>
>>In fact it is written
in the UNI doc (table 12-5) that there are some UNI
>>objects that
have end-to-end significance. For example Source and
>>Destination
TNA addresses have end-to-end significance. This
doesn't
>>mean, as you pointed out, that there is an UNI session
between two UNI.
>>
>> Anyway the question is (this is my
interpretation of Gino's message so
>>please, Gino, correct me if I'm
wrong) how can I transport/map the UNI
>>end-to-end significative
information between the two UNIs?
>>
>>AFAIK there is no
room in GMPLS extended LDP and RSVP for this
purpose.
>>
>>Are there any efforts in IETF to harmonize OIF
UNI and GMPLS extended
>>LDP/RSVP?
>>
>>Regards,
Diego.
>>
>>----------------------------------------------------------------
>>Diego
Caviglia
>>Optical Network - ASON strategy
>>E-mail: diego.caviglia@marconi.com
>>Tel:
+39 0 10 6003 808
>>Via A. Negrone 1A 16153 Genoa
(Italy)
>>http://www.marconi.com
>>
>>"Lazer,
Monica A, ALCNS" <mlazer@att.com>@ops.ietf.org
on 10/04/2002
>>04.41.05
>>
>>Sent by: owner-ccamp@ops.ietf.org
>>
>>To:
"Gino Carrozzo" <g.carrozzo@cpr.it>, "ccamp" <ccamp@ops.ietf.org>
>>cc:
<braja@tellium.com>
>>
>>Subject:
RE: UNI end-to-end sessions
>>
>>All,
>>I want to
correct some mis-representations - There is no end-to-end
UNI
>>session. A UNI session is between a user and the network. There
is a
>>separate UNI session at the other edge of the network, between
the other
>>client and the network. Further more, it should not be
assumed that the
>>same protocol must run over the 2 separate
UNIs.
>>
>>Monica A. Lazer
>>Advanced Transport
Technology and Architecture Planning
>>
>>908 234
8462
>>mlazer@att.com
>>
>>-----Original
Message-----
>>From: Gino Carrozzo
[mailto:g.carrozzo@cpr.it]
>>Sent: Tuesday, April 09, 2002 5:45
AM
>>To: ccamp
>>Cc: braja@tellium.com
>>Subject: UNI
end-to-end sessions
>>
>>All,
>>
>>when
establishing an end-to-end UNI-RSVP session between two UNI-Cs (src
&
>>dest. UNI clients),
>>I didn't found any reference
in how to "transfer" UNI end-to-end info from
>>the source
client side (source UNI-C <--> UNI-N on source TNE) to
the
>>destination client side (UNI-N on dest. TNE <-->dest
UNI-C).
>>In draft-bala-uni-signaling-extensions-00.txt, only the
UNI-C / UNI-N side
>>is considered.
>>
>>How the
two UNI-N can exchange UNI infos in the transport network?
>>Is there
any action in this WG (or in IETF) to fix this
problem?
>>
>>Thanks
>>
>>Gino
>>
>
>
|