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@bnl.gov tel: 631-344-4008 fax: 631-344-5751