GN2 SA3 Provisioning System Development Meeting

Date

Location

Type

Attended By

Apologies

Summary of Actions:

• [MK] to update the WIKI with latest Reservation module design.
• [MK] to load the Reservation module code and jUnit test cases to CVS.
• [ALL] review design.
• [DANTE/PSNC] to finalise the schema and WSDL for intra-domain PS.
• [MK] to investigate these two interfaces at link and path level and add it to the Utilisation module design and code.
• [AP] To check on this with asynchronous interface EGEE.
• [BB] to look into transaction module being split into 2 layers.
• [BB] to add current domain to seen domain list to the inter-domain interface.
• [BB] to update WIKI pages communication module – forwarding layer, transaction layer and reservation layer.
• [GRNET] to check if they keep/can keep next domain PS URL information in the NIS.
• [GRNET] to update pathfinder schema / WSDL as discussed above.
• [GRNET] to give possible faults for Pathfinder.
• [GRNET] to give dates for their tasks by next Friday.
• [GARR, UKERNA] investigate how to populate their NIS with data for their network before October 2005. GRNET can give information about what tables are required to be filled with data.
• [AS] to send information about their PIP reservation tool
• [TR] to check with GARR and UKERNA about PS deployment and PIP implementation plans.
• [ALL] to work on design document to be submitted to EC.
• [AP] to give hardware requirements for deploying PS.
• [GRNET] to document policy module on WIKI
• [BB] to update forwarding layer details on the WIKI. This includes the description, WSDL and schema.
• [BB] to investigate how to carry undefined payloads in SOAP message wrapped in defined wrappers.
• [PSNC] to investigate use of XML property files and disseminate information on the mailing list.
• [BB] to define all transaction layer interfaces on the WIKI.
• [BB] to describe various transaction scenarios on the WIKI
• [AP] to send EGEE WSDL and schema to SA3 dev mailing list.
• [PSNC] to give detailed breakdown of tasks, effort.

Day 1 - Tuesday 26 July 2005

AS/APO could not make it on the first day due to personal reasons. Present AP, BB, MK, MP. Agenda reorganised for this reason.

Date of next meeting proposed as 13-15 Sep 2005. PSNC staff available but finances need to be sorted out. Discussion deferred to the next day once GRNET people arrive. The meeting after that AP prefers it to be in October before the 31 October 2005 phase 1 delivery deadline. BB and MK prefer it to be after the 31 Oct 2005 deadline - TBD.

Status from PSNC

Intra-domain PS: Reservation module design - 100 % done. Reservation module development - 90 % done - MK confirmed that coding, self-testing using jUnit test cased will be done by 05 Aug 2005.

[ACTION] MK to update the WIKI with latest Reservation module design. [ACTION] MK to load the Reservation module code and jUnit test cases to CVS. [ACTION] OTHERS review design.

Utilisation module design 100% done. Utilisation module development NOT STARTED - MK confirmed that coding, self-testing using jUnit test cases will be done by 26 Aug 2005. [ACTION] MK to update the WIKI with latest Utilisation module design. [ACTION] MK to load the Reservation module code and jUnit test cases to CVS as development progresses. [ACTION] OTHERS review design.

Status from GRNET will be done the next day.

[DECISION] Code for intra-domain and inter-domain PS will be kept in the same CVS with an ANT task creating 3 separate jar files with appropriate classes for inter-domain PS and intra-domain PS and common classes. This can be split into 2/3 separate projects if it is found infeasible.

Intra-domain PS discussion

[DECISION] The interface between inter-domain PS and intra-domain PS will be synchronous. [MK] There is a need for a component that will handle the business logic and call the Pathfinder, Reservation module and Utilisation module to make a reservation. [AP] This can be called the controller. [BB] We also have to think about where the Policy module and the Configuration module will fit in. [AP] These two can be components inside the intra-domain PS or can be separate web services. This needs to be further evaluated at a later date. At first we should concentrate on phase 1 delivery.

[DECISION] DANTE to develop the intra-domain PS web service interface and controller. The controller does the following:

1. Call pathfinder to find the internal path.
2. Call Policy Module to check that the request does not violate the local policies (for future use)
3. For each link (or for entire path) call Utilisation to check if enough capacity is available for the given reservation.
4. If capacity is available call Reservation module to create a reservation.
5. Call utilisation module to update the utilisation values.

[AP] I think it would be better for the reservation module to directly contact utilisation for step 4. [MK] I do not agree.

[ACTION] DANTE/PSNC to finalise the schema and WSDL for intra-domain PS.

[AP] The current Utilisation module has low level interfaces. IT does not answer the question what is the max possible bookable capacity on a given link/path. Also we need another higher level interface to add/subtract given bandwidth to/from a given link/path. [MK] Yes, these should be added to the Utilisation module. Using the current low level interfaces, it will be easier to do this on a link basis. Add/subtract bandwidth can be done using a single interface with positive and negative values. [AP] For efficiency we should evaluate if it can be done on a path basis. Perhaps two interfaces for add and subtract would be more intuitive. [ACTION] MK to investigate these two interfaces at link and path level and add it to the Utilisation module design and code.

Inter-domain PS discussion

[BB, MK] The interface between client and inter-domain PS will be asynchronous. [AP] This issue needs to be evaluated as EGEE were expecting a synchronous interface. [ACTION] AP To check on this with EGEE. [BB] The interface between inter-domain PS will be asynchronous. [AP] WE have to be careful in our design to ensure that transactions do not get lost or stop midway due to asynchronous nature of design.

[BB, MK] We think 1-phase commit is sufficient for our requirements. [AP] We cannot be sure of that. Industry standards recommend 2-phase commit for proven reasons. So at the bare minimum we should split the transaction layer into 2 interfaces. Low level interfaces that are independent of whether it is 1 or 2 phase commit. And higher level business logic that uses the lower level interface to build a 1 phase commit framework. The idea is that in case we need to move to a 2 phase commit scenario we should be able to reuse the low level interfaces. [ACTION] BB to look into transaction module being split into 2 layers. [AP] To support this idea we can use event driven 1 phase commit framework. In the intra-domain system it would be as simple as keeping another status for the reservation.

[AP] On every hop the current domain can add its own domain id to the list of domains on the path. [MK] Can't see how this will be useful but it can be added. ([Post Meeting note by TR] This will provide a simple but effective way to check if there is a "routing loop"). [ACTION] BB to add this to the interface. [Postnote] AP This can be used to check for routing loops.

[ACTION] BB to update WIKI pages communication module – forwarding layer, transaction layer and reservation layer

Day 2 – Wednesday, 27 July 2005

Inter-domain PS requirements for Pathfinder

getNextHop – need to know whether there is a next hop with a PS deployed; if yes then the URL of the PS in the next domain along the path towards the destination.

getEgress – find the egress node and interface towards the next hop

Intra-domain PS requirements for Pathfinder

getPath – given the ingress and egress interface the internal path from the ingress to the egress.

[AS] If router IP addresses changes (or any other change in the network) it may not be notified to the PS topology DB. [ASSUMPTION] Topology DB will always be up to date.

Inter-domain interface to pathfinder

• Input - source address, destination address and ingress interface
• Output – egress interface, next domain ingress interface and URL of next domain PS

Intra-domain interface to pathfinder

• Input - source address, ingress interface and destination (where destination can either be the destination address or egress interface)
• Output – path (comprising of a list of hops; hop being A end interface, B end interface and the characteristics of the hop e.g. total allowable premium IP capacity)

[MK] Pathfinder needs to return the hop by hop total premium IP capacity. [AS] Agree

Pathfinder Interface

Input:

• flag – to indicate type of request
• pathType – routed of constrained (for intra-domain only)
• source – source IP address
• destination – destination IP address
• ingress – ingress interface in the current domain (optional)
• constraints – for future use (optional)

Output:

• egress interface
• next domain ingress interface
• next domain PS URL (if null implies there is no next domain)
• path (containing a set of)
  • Links (containing)
  • A end interface
  • B end interface
  • PIP capacity

[AP] The information about next domain PS URL should be in NIS. [ACTION] GRNET to check if they keep/can keep next domain PS URL information in the NIS.

[ACTION] GRNET to update pathfinder schema / WSDL as discussed above. [ACTION] GRNET to give possible faults for Pathfinder. [ACTION] GRNET to give dates for their tasks by next Friday.

[MK] There is always the issue of how to load data into the network topology DB. [AS] Each domain is responsible for loading data into its own NIS. [AP] For phase 1 this can be done manually or by using simple spreadsheets or comma separated files. But eventually there should be a better way e.g. web based front end to manage data in the topology DB. [BB] Next phase should automate NIS data population.

[ACTION] GARR, UKERNA – how to populate their NIS with data for their network before October 2005. GRNET can give information about what tables are required to be filled with data.

[ACTION] AS to send information about their PIP reservation tool.

GRNET to demo Pathfinder at the next meeting in Cambridge. This should be added as an agenda item.

Tele-conference with Toby Rodwell

13-15 Sep dates are OK for all – meeting to be arranged at Cambridge. Financial issues to be checked.

[ACTION] TR to check with GARR and UKERNA about PS deployment and PIP implementation plans.

[ALL] to work on design document to be submitted to EC.

[ACTION] AP to give hardware requirements for deploying PS.

[TR] Who will write the installation guide? [AP] This should be done by the development team and be validated by a non-development partner. [ACITION] TR to check with non-development partners [AP] Non development partners can also be given the task of writing independent test scenarios and test cases based upon requirements and high level design document. [TR] We will also need to assign timescales for these tasks.

Continuation after Teleconf

Policy Module

[AP] Policy module has a scope which is limited within the domain. It has nothing to do with neighbouring domains except perhaps propagation of policy. The basic requirement is to send user credentials and the user request to the policy module and get back a yes or no response. Policy module may ask the intra-domain PS for utilisation by user/group information.

[APO] There will be three interfaces to the policy module

1. Admin interface – create policy modify policy, delete policy etc
2. Operational interface – respond to queries whether policies allow user request
3. Propagation interface – for propagation of policy across domains

[AP] We will start with operational interface first and look at the interfaces in subsequent phases.

Input parameters: User credentials Requested capacity, start date-time and end date-time Source and destination (if policy is to be source/destination aware) Is burst size required?

[APO] If policy is to be based upon a quota system its implementation will be very complex. It is not easy to keep track of future additions to quota for current requests spanning long time frames. It would be easier to start with a simple rate based system.

Information required for making a policy decision

For each group we need parameters like:

• Min capacity
• Max capacity
• Min duration
• Max duration
• Replenish value
• Replenish duration
• Q-max
• Quota(s)

[AP] There can be other features like black listing based upon source or destination IP addresses. This will require an addition to admin interface as well.

[ACTION] GRNET to document policy module on WIKI

[DECISION] At first only operational interface will be implemented.

Day 3 – Thursday, 28 July 2005

Forwarding Layer

[BB] The basic aim of a forwarding layer is to forward messages towards their destination. Once the message has reached its destination domain it should be handed over to the appropriate layer above.

[AP] OK on an abstract level the forwarding layer takes a payload, payload type and final destination as its input and transmits the payload towards its destination domain. Once the payload reaches the destination domain the forwarding layer extracts the payload and depending upon the payload type hands it over to the appropriate upper layer.

[AP] We should standardise the protocol with a self generated unique message id in the forwarding layer and log messages sent and received for debugging/troubleshooting purposes.

Exceptions

We can expect following exceptions:

• Unknown destination format exception
• Unknown payload type exception

[BB] The logic of the forwarding layer is simple. When a message comes in call the pathfinder to check the next domain PS URL for the given destination. If the pathfinder returns a next domain PS URL then forward the message to the next domain. If the URL is null (this is the last PS) then handover the message to an internal dispatcher. The internal dispatcher will have various handlers registered (perhaps using namespaces or message type) which will forward the message to the appropriate layer above the forwarding layer.

[AP] We can also check if the destination is the current domain ID in which case we can avoid a call to the pathfinder.

[BB] We can look into that. [ACTION] BB to update forwarding layer details on the WIKI. This includes the description, WSDL and schema.

[ISSUE] How to send undefined payloads inside a SOAP envelope? We could use type ‘any’ as a wildcard and user pure document literal to handle the XML ourselves and then users our own parsers/un-marshallar.

[BB] Can we use axis to do this?

[AP] Needs to be investigated – as a last choice we can always use a schema with a choice for the payload.

[ACTION] BB to investigate how to carry undefined payloads in SOAP message wrapped in defined wrappers.

[DECISION] We should use commons logging with log4j below it. As of now we will use log4j properties file. [ACTION] PSNC to investigate use of XML property files and disseminate information on the mailing list.

Transaction Layer

Definitions: User home domain = domain where user credentials are stored Service home domain = domain where the user contacted the PS and where the transaction starts and transaction manager resides

[ACTION] BB to define all interfaces on the WIKI.

[BB] There can be only one transaction on a SID at a time. This is to ensure user cannot send a cancel transaction while the reserve transaction is still in progress.

[AP] To do this transaction layer will need an API like boolean isTransactionPending(SID)

[AP] Also need to define transaction in progress fault.

[ACTION] BB to describe transaction scenarios on the WIKI for following cases:

• Transaction success
• Transaction Failure in the first domain, middle domain or last domain
• Transaction Failure – send rollback – rollback successful
• Transaction Failure – send rollback – rollback fails
• Transaction Failure due to timeout

[AP] add a list of domains to the Transaction layer message – This will be a list of domains traversed along the path. [MK] This may not help.

Use of timestamps: Use timestamps in local domains. Do not rely on timestamps for any synchronisation => No logic should be based upon timestamp comparison between different domains. Assume that clocks on different machines are NOT is sync.

[BB] We need to pass user credentials in reservation messages.

[AP] As of now that can be done until JRA5 gives us a better scheme.

[AP] Transaction logging should be done at Transaction layer. Operation logging should be done at reservation layer.

[ACTION] AP to send EGEE WSDL and schema to SA3 dev mailing list.

[ACTION] PSNC to give detailed breakdown of tasks, effort.

-- AnandPatil - 1 Aug 2005