Hi all --
I would like to bring your attention to the OGF NSI wg work. What
NSI is working on seems to be very similar to at least part of what
ESCP LDC (if I understand it right) is doing or might use. One way to
think of NSI (Network Service Interface) is that it is an enhancement
to IDC protocol to include capabilities in other transport request
implementations. Some of the issues being discussed in this list are
also discussed at NSI. It seems to me that the two could help each
other - NSI by including requirements from ESCP and ESCP by using the
basic framework from NSI and possibly evolving to use NSI as a
standard in the long run - if practical.
I note that NSI uses NML naming for data plane concepts, with
extensions as necessary.
Note that NSI is a protocol to an transport group which can provide
connections between end points. The name of end points is not final,
but is likely to be port or Service Termination Point (still being
discussed). NSI assumes a Domain Controller to manage real
resources. In NSI we have started describing the entity that includes
NSI as Actors. An Actor has multiple roles, one of which might be a
NS requestor, another might be a NS server. In the ESCP case the
Actor might have and ESCP role as well.
A couple NSI concepts that might be applicable.
1) a request is for a connection between two points (in the long term
this might be expanded to multipoint. is that required by ESCP?)
2) a connection might be a VLAN, a flow, a wave. each have different
performance parameters
3) a connection is at a single level (level == VLAN/ flow/ wave/?) --
ESCP seems to be doing multilevel connections, which I think is very
complicated. It would be good to understand any interface
requirements that you come up with for multiple level (e.g. creating
VLAN to carry multiple flows)
-- a question -- it seems to me that ESCP is oriented to multi-level
capability at the end sites and using/ creating paths between sites
that carry multiple connections (or flows). is this a right
understanding?
4) a connection is made over a path. a path may consist of multiple
segments. a request contains a path that has one or more segments.
Any requirements for how multiple segments are supported - if at all -
would be helpful to NSI
5) it seems that ESCP is planning to require LDCs to collaborate
before making IDC connections. This seems a good idea - but may be a
protocol different than IDC. What do you think -- it may include more
than transport resources, perhaps storage or compute or application
resources. If so, perhaps it could use transport oriented NSI as a
part of the protocol.
The documents for NSI architecture are "in progress". A slide set
that is a work in progress is attached - many details are still being
discussed and expanded, but it gives and idea of what is being done.
Let me know if you have questions. I generally am not available on
Friday afternoons, so I can't join most calls but I try to follow this
list - If you would like I could rearrange a particular week to
make it.
I hope this is helpful. I appreciate feedback.
John
On Dec 9, 2009, at 12:58 PM, Dimitrios Katramatos wrote:
> Ezra, I'm not sure I understand your point here.
> It sounds to me like you're saying we should extend OSCARS to run on
> an endsite
>
>
>
> Ezra Kissel wrote:
>> I had some of the same concerns when I discussed the LDC/IDC issue
>> with Martin a while ago, and I'm not sure I've been persuaded
>> either way yet. :) I do know that there's something to be said for
>> trying to keep ESCPS components as general as possible, and given
>> the availability of OSCARS and the existing role it fills, it seems
>> worth our while to investigate how we can extend the APIs and
>> existing functionality to meet both goals.
>>
>> Correct me if I'm wrong, but in my mind OSCARS IDC already provides
>> a form of local site configuration based on the local domain
>> topology that's provided either statically or through TERCE/
>> perfSONAR. When a reservation is requested, each IDC instance
>> along the path must exchange capabilities and execute a local
>> domain configuration to make the circuit available, typically via
>> dragon vlsr or vendor specific CLI commands. Obviously, those
>> functions are not exposed through the client API, and one of our
>> goals might be to investigate how we might extend and formalize
>> this functionality to fit our requirements for an LDC.
>>
>> In regards to Trac and content management, Trac is really designed
>> to manage code repositories like subversion with associated
>> tickets, bug tracking, and milestones. In terms of content
>> management, the most it can provide are the Wiki pages with file
>> attachments. I agree we need a more powerful way to manage our
>> increasingly numerous documents. I'll take a look at what else is
>> readily available and is also easy to configure, but I think Phil
>> suggested it might be best to at least keep our public facing pages
>> on a .gov domain.
>>
>> - ezra
>>
>> Dimitrios Katramatos wrote:
>>> Correct. The LDC component configures the local network.
>>> It doesn't even have the notion of reservations.
>>> I don't think it's possible to have an API that even comes close
>>> to IDCs.
>>> getCircuitInfo retrieves information about the configuration
>>> related to a circuit.
>>> Multiple flows, resulting from different reservations may be
>>> directed into the same circuit.
>>> Flows may be split between different circuits for different
>>> reasons, e.g., preferred routing, redundancy, total capacity.
>>>
>>> Now, at the ESCPS service level, the API could be similar to an IDC.
>>> But I'm quite sure there will be differences.
>>> For example, taken from the ongoing StorNet work, a TeraPaths
>>> "createReservation" will have to figure out how to match resource
>>> availability across all domains to satisfy a request given certain
>>> tolerances in the parameters and may return multiple reservations
>>> if a single solution is not found. These reservations may be
>>> associated with the same or different IDC reservations.
>>> So, the "standard" createReservation will not do.
>>>
>>> Dimitri
>>>
>>> Andrey Bobyshev wrote:
>>>> Hi Martin,
>>>> If LDC and IDC are the same why do we need both ? A
>>>> getCircuitInfo - is more like getting information about physical
>>>> construction, where listReservations is a service related. On
>>>> same ckt I may have multiple reservations in same time. I also
>>>> should mention that most of LDC API calls that I listed are
>>>> internal to ESCPS and not exposed to ESCPS users/applications.
>>>> But they will be needed internally to interact with LAN when an
>>>> ESCPS user/application will submit "createReservation" request.
>>>>
>>>> If I take Lambdastation as an example, I certainly cannot make
>>>> IDC/LDC API the same. However, requests submitted by a user/
>>>> application to LS look similar to OSCARS's in terms of parameters
>>>> although not identical because of a difference in the concept. I
>>>> also checked TeraPaths API and I see a lot overlaps with LS...
>>>> But let's see what Dimitri is going to comment..
>>>>
>>>> - Andrey.
>>>>
>>>>
>>>> Martin Swany wrote:
>>>>> Hi Andrey,
>>>>>
>>>>> (We should discuss the document management issue as well. I
>>>>> think trac is powerful, but I admit that I don't understand all
>>>>> its
>>>>> features. What you suggest would indeed be ideal.)
>>>>>
>>>>>> I don't think I suggested to deviate.. If we look at the ESCPS
>>>>>> architectural picture, there are LDC and IDC components. LDC
>>>>>> faces LAN and IDC faces DCN communicating via OSCARS. In the
>>>>>> document which I sent, an IDC is not showed because I planned
>>>>>> to discuss only LDC API specs.. I believe, IDC API spec we just
>>>>>> have to use as is will be provided.
>>>>>
>>>>> I wasn't really clear. I think that we should look at the IDC
>>>>> and LDC
>>>>> models as the same until we need to differentiate them. My
>>>>> personal
>>>>> hypothesis is that we can can use the same framework for both and
>>>>> that we can abstract or specialize as necessary. I didn't
>>>>> really mean
>>>>> that we're "deviating" but rather that when you say
>>>>> getCircuitInfo(),
>>>>> it seems to map to ListReservations(reservationID) in the OSCARS
>>>>> API. (That might be a poor example.) The point is that we
>>>>> should try
>>>>> to re-use that API and extend it when it is lacking. I think
>>>>> this also
>>>>> includes generalizing terminology. (I.e I don't expect this to
>>>>> be a
>>>>> one-way street.) Speaking of terminology, I'm still not sure
>>>>> that we
>>>>> all agree with terminology document 1.2. (I know that I don't,
>>>>> but I'm
>>>>> willing to accept the group decision if that's what it is!)
>>>>>
>>>>> Hope this is not too rambly. It's late...
>>>>>
>>>>> best,
>>>>> martin
>>>
>
> --
> Dimitrios Katramatos, Ph.D.
> Computational Science Center
> Brookhaven National Laboratory
> Building 463B, room 255
> Upton, NY 11973-5000
> email: dkat(a)bnl.gov
> tel: 631-344-4008
> fax: 631-344-5751
