[Nsi-wg] interim call tomorrow
t.kudoh at aist.go.jp
Wed Nov 4 09:10:56 CST 2009
Hi Chin and all,
I just mapped Chin's components to the modules of my architecture
proposal at OGF27 meeting.
External interface: NSI server module & NSI client module
- I think north interface and south interface should be distinguished.
This is not a classification based on the functionality the agent provides.
Topology manager: Agent finding service?
- Now I think AFS is not an appropriate term here. It represents
whatever external service.
NSA Look up service: Agent selection module
Local Resource Coordinator: Local Resource Manager Module
Authentication service: included in the NSA server module and NSA client module
- making this separate and clear is good.
Authorization service: not clearly defined in my architecture
Notification service: not clearly defined in my architecture
- whether to have notification mechanism or not is a matter of the
server module and client module
- the information to be provided to the client is naturally prepared
by the aggregation module
Path finding service: ?
- I am not sure the definition and the difference of NSA look up
service and this service
2009/11/4 Chin Guok <chin at es.net>:
> Hi all,
> Here's an initial draft of the NSA functional components. There are some
> comments from Radek that I left inline for discussion.
> - Chin
> --On November 3, 2009 2:43:56 PM -0500 John Vollbrecht <jrv at internet2.edu>
>> We will have an interim call tomorrow. My proposed agenda is to
>> talk about work under way, I suggest
>> 1. Joan's slides modified from OGF
>> 2. Review block diagram - from Tomohiro slides at OGF
>> 3. Go over status -- my view of where we are is below.
>> I am hoping we can make some progress before SC, and then have
>> sections 2,3, and 4.b, 4.h, 4.j. and part of section 5 available as
>> candidate sections for the recommendationrecomendation -- by the end of
> the year.
>> We can talk about whether this seems possible.
>> My view if status - please comment --
>> I am thinking that we need to make some progress on actual document in
>> the next few weeks. Progress for me will be to have some sections in
>> place that are ready for detailed editing.
>> Section 1 - Summary and Abstract [to be done]
>> Section 2 - Context and Motivation
>> I think we are close on the first part section 2 the context and
>> motivation. I keep thinking of some changes to it as I go along,
>> but I think it is ok as a starting point for editing.
>> We are planning a second part of section 2 that describes service and
>> transport planes and their relation to other planes. I believe that
>> Inder will propose something for that.
>> Section 3 - Concepts and Terminology
>> We have documentation that covers most of this. However, in my view,
>> after rereading in a couple times, it needs to be revised to
>> correspond with the NSA model that we came up with in Banff,
>> particularly the concepts of Agent Selection and Aggregation, and the
>> naming of NSI server and client model. I think we should talk this
>> through on the call to be sure we all agree and I can rework the
>> I believe that the transport terms described in the second part of
>> this section are ok for a version to be edited. I will modify the
>> order of some of this section when I do the first part.
>> Section 4 -- Architecture (details)
>> 4.a Services offerred over NSI [hold till after 4.b]
>> 4.b Block diagram of requestor and service agents
>> This will build on diagrams from Tomohiro at OGF. Chin has
>> to provide a first cut at all modules. Many are are interested in
>> helping to define this, including Chin, Radek, Tomohiro, Joan and
>> others]. I believe the hope is that discussion on this can occur on
>> the skype chat as well as on calls and email.
>> I think that this is key to defining much of the rest of the
>> document. The blocks help define what is done by an agent, and allow
>> the agent to use interfaces other than NSI by some blocks. It also
>> helps explain the recursive nature of calls to other NSAs. It also
>> helps to clarify what a request needs to contain.
>> This is a NSA architecture section that provides context for the NSI
>> 4.c Domain interaction --
>> As I think about this, which I believe Tomohiro proposed, I think it
>> is meant to define what a domain is, especially relative to a NSA. I
>> am thinking this might better be called "recursive NSAs" or hierarchy
>> imposed by aggregation module, or something else. Any thoughts about
>> 4.e Responsibiliy division between Management, Control, Transport, and
>> Service Plane.
>> I am not sure how this will be different that section 2.2, except more
>> 4.f Security and Accounting (I have volunteered for a first cut at
>> this, but not till earlier sections are farther along)
>> 4.g. Deployment [of multiple NSAs] architecture [hold till earlier
>> sections done]
>> 4.h Messaging interaction [ Tomohiro has volunteered to take the lead
>> on this]
>> two phase commit (required or not), synchronous / asynchronous
>> message triggers
>> path description in reservations - I will take initial lead on
>> 4.i Request and Response messaging characteristics
>> Resources (objects) and parameters, and their topology [Guy]
>> Section 5 Imlementation and Deployment frameworks
>> Overview [Joan, Tomohiro, John, Inder]
>> Using NSI in othe models - GMPLS, GRID, GENI [John, Joan]
>> Application examples of NSI - [KDDI, LHC, CoUniverse, other?]
>> nsi-wg mailing list
>> nsi-wg at ogf.org
> nsi-wg mailing list
> nsi-wg at ogf.org
More information about the nsi-wg