Subject: RE: Questions concerning: draft-yu-mpls-rsvp-oif-uni-00.txt

From: Fong Liaw <[email-masked]>
Date: Thu, 30 Nov 2000 13:55:50 -0800

Dimitri
 
Regarding the address format. There is an agreed requirement
to do "address resolution" for exactly the reason you mentioned.
If the network's native address format is not IP, then it may make
sense to use another format in Session object. This can be easily 
extended, but  they will still be assigned by user, not the network. 
 
John is in the process of writing this up which would include procedures
and object format.  Note that the UNI optical nodes still need
to have an IP address since all the control messages using IP.
 
How do you know the destination client's address, just like telephone
numbers, you get it from other source.
 
-Fong

-----Original Message-----
From: Papadimitriou Dimitri [mailto:[email-masked]]
Sent: Thursday, November 30, 2000 1:06 PM
To: [email-masked]; mpls
Subject: Questions concerning: draft-yu-mpls-rsvp-oif-uni-00.txt

Hello, 

I have some questions concerning the draft:
draft-yu-mpls-rsvp-oif-uni-00.txt 

The official name for ligthpath ID is now "Connection_ID", So 
By refering to the draft: draft-many-carrier-framework-uni-00.txt 

3.3.1 Identification Attributes 

   [...] 

   - connection identifier: a globally unique identifier for the 
     connection.  This identifier will be assigned by the network.  The 
     globally unique connection identifier will be created using a 
     globally unique carrier identifier (identifying the carrier from 
     which the connection request is sourced) and a carrier unique 
     connection identifier.  This attribute is not modifiable (i.e. 
     cannot be modified using the modify command). 

By refering to the draft: draft-yu-mpls-rsvp-oif-uni-00.txt 

3.2.4 Lightpath_ID Object 
  
   The Lightpath_ID object is used to uniquely determine a lightpath 
   within the optical network. Lightpath_ID object has the following 
   format:  
  - IPv4 source address: This is the address (32 bits) for the source 
     UNI-C who originates the lightpath. 
  - IPv4 destination address: This is the address (32 bits) for the 
     destination UNI-C who terminates the lightpath. 
  - Ligthpath number: This is the unique identifier (64 bits) in the 
     network to be associated with the lightpath. 

Questions are the following: 

I think that carrier identifier means 'optical network identifier' not the 
client network (so the UNI-Client address should not be the included 
within the lightpath ID) ? 

Secondly i do not understand why the ONE has to assign an IP address
belonging 
to the signaling plane. Imagine that the address space of the signaling
plane 
(i.e. control plane) changes then you have to change all the identifiers of 
the lightpaths (or connections) which by definitions are included within the

transport plane. This solution does not guarantee the independancy between 
the signaling and the transport plane. Do you agree ? 

Imagine that you may use the UNI-C as identifier, then I do not understand
why 
you need to include the destination UNI-C IP address within the lightpath
ID. 
Moreover, how do you know the relationship between UNI-C and the destination

client address (or name) ? 

Regards, 

Dimitri.

---

From: Papadimitriou Dimitri <[email-masked]>
Date: Fri, 01 Dec 2000 00:21:33 +0100

Hi all,

If refer to the new version of this draft:
draft-many-carrier-framework-uni-01.txt
(Thanks Yangguang to make the remark.)

The lightpath ID is identified as: A network-wide unique 64-bit
identifier for a
lightpath. This identifier is assigned by the optical network (dxit)

And in fact most of the parameter definitions map the carrier
requirement
draft which is the following: carrier-ID - identifier whose draft is
'the guideline'
for the definition of the parameters at the OIF as far as i now (or it
has change
from the last OIF meeting in MAUI until now)

Moreover, there is no relationship between the source and destination
address (of the client address space) and the lightpath identifiers.
UNI-C and UNI-N IP addresses are dedicated to IP signaling between
the client and the network not to identify the lightpaths nor the source
and
destination address of the lightpath create requests.
Source and destination included within the create request are defined as
(dixit 6.3.1)
3. Source/destination client point of attachment: This has two
    components, an optical-network-administered IP address and an
    optional logical port information. The latter consists of a port
    index, a channel index and a sub-channel index.

The question related to destination UNI-C, is that the source ONE does
not know
the destination UNI-C address (simply it does not have to know this
address).
The lightpath create request is sent from the source to the destination
IP address
of the source and destination ONE.

Dimitri.

Fong Liaw wrote:

>  Dimitri Regarding the address format. There is an agreed
> requirementto do "address resolution" for exactly the reason you
> mentioned.If the network's native address format is not IP, then it
> may makesense to use another format in Session object. This can be
> easily extended, but  they will still be assigned by user, not the
> network. John is in the process of writing this up which would include
> proceduresand object format.  Note that the UNI optical nodes still
> needto have an IP address since all the control messages using IP.How
> do you know the destination client's address, just like
> telephonenumbers, you get it from other source.-Fong
>
>      From: Papadimitriou Dimitri
>      [mailto:[email-masked]]
>      Secondly i do not understand why the ONE has to assign an IP
>      address belonging
>      to the signaling plane. Imagine that the address space of
>      the signaling plane
>      Imagine that you may use the UNI-C as identifier, then I do
>      not understand why
>      you need to include the destination UNI-C IP address within
>      the lightpath ID.

---

From: Papadimitriou Dimitri <[email-masked]>
Date: Fri, 01 Dec 2000 01:51:37 +0100

Hi,

Concerning the lightpath Identifier:

The lightpath ID is identified as: A network-wide unique 64-bit
identifier for a
lightpath. This identifier is assigned by the optical network (dixit)

The UNI-C and UNI-N IP addresses are dedicated to IP signaling between
the client and the network not to identify the lightpaths nor the source
and
destination address of the lightpath create requests.

You wrote:
>How do you know the destination client's address, just like
telephonenumbers, you get it from
>other source.-Fong

The question related to destination UNI-C, is that the source ONE does
not know the destination
UNI-C address (simply it does not have to know this address). The
lightpath create request is sent
from the source to the destination IP address of the source and
destination ONE.

The question is not how the source client address knows the destination
client address (transport
plane) it is related to the knowledge of the destination UNI-C client by
the source UNI-C address
(signaling plane) ? I don't know where you find this requirement ? From
what it is currently proposed
ONA-IP addresses are defined to virtualize 'client address space' at the
UNI.

Even in case of unnumbered client end-point, the address you should not
assign the UNI-C of the client
as a potential identifier (since belonging to the signaling plane - this
is currently under study); however
the address resolution request (for the destination) will give the
corresponding address within the optical
network which is the ONA-IP corresponding to this client end-point, so
your request won't contain the UNI-C
destination address of the CNE.

Dimitri.