Subject: Queries on Signaling requirements at the optical UNI, draft-bala- mpls-optical-uni-signalling-00.txt

From: Shen Gangxiang <[email-masked]>
Date: Sat, 14 Oct 2000 18:07:43 +0800

Hi, folks,

I have a query on the draft: Signaling requirements at the optical UNI,
draft-bala-mpls-optical-uni-signalling-00.txt

When a UNI-C sends a Light-path Create Request to a UNI-N, the message uses
(1) Source termination Point, IP address, (2) Destination termination Point,
IP address, (3) Source termination point, port, Channel, Sub-Channel, and
(4) Destination termination point, port, Channel, Sub-Channel to identify
the exact source and destination addresses of the lightpath. To achieve
this, this means that the UNI-C must have the information on the reachable
IP addresses of all OXCs (i.e. IP addresses that can be accessed by an OXC).
Based on this information, UNI-C decides the destination OXC and its logical
interface of the lightpath. If these address information could be exchanged
between UNI-C and UNI-N through "neighbor discovery" procedure, this
approach of course can work. 

However, I wonder if we could use the IP addresses of the initiating and
terminating UNI-Cs to substitute those information in (1)-(4). The detail
suggestion is as follows: using the "neighbor discovery" procedure, we
register the client IP address and user group identifier with the optical
network, then the optical network employs IGP protocol to flooding these
address-reachable information around the network; each time when an OXC
receive a Lightpath Create Request that includes the IP addresses of the
initiating and terminating UNI-Cs, it calculates the route for the lightpath
and then trigger the signaling process to build up it. After the light-path
is established successfully, the OXCs in the both terminations inform their
corresponding UNI-Cs on this event. 

With such a modification, the optical network will look like a black-box
except some interfaces to communicate with UNI-Cs. Moreover, there will be
less information exchanged on UNI interface. 

Above is my idea. If it is not so correct, please kindly point out. Thanks!

Gangxiang

---

From: Yangguang Xu <[email-masked]>
Date: Mon, 16 Oct 2000 10:59:16 -0400

Gangxiang,

It's a good idea. Actually, it has been used by some ATM vendors for IP/ATM
address resolution. Yet, there are several other address resolution mechanisms.
There is no need to specify the solution in the UNI signaling specification
(recommendations are always welcomed).  Different vendors may choose different
ways within their own cloud.

Regards,

Yangguang