The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Nov> msg00377



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

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

  • From: Fong Liaw <FLiaw@zaffire.com>
  • 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:Dimitri.Papadimitriou@alcatel.be]
Sent: Thursday, November 30, 2000 1:06 PM
To: FLiaw@zaffire.com; 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.