InterDomain Controller Protocol (IDCP)
Possible Future Features and Issue List
LightPath Monitoring and DebuggingDevelop mechanisms and messaging to allow for debug and isolation of lightpath problems. This should consider issues both at signaling time and failures that occur after circuit has been established. This should also include interoperation with PerfSonar processes. Improved logging and status reporting for inter-domain messages may be a critical part of this. There was general agreement that this is an important item. Problems during circuit set phase should generally be handled by the IDC protocol and messaging directly. Subsequent debugging should probably be handled by distributed monitoring systems like PerfSonar with assistance from IDC. It was noted that we will need to make a distinction between protocol issues/changes and implementation issues/changes. It was also noted that we may need to increase the amount of regular logging and status reporting that the IDC supplies to the PerfSonar infrastructure.
DICE IDCP StandardizationWork with OGF and GLIF to ensure that that DICE IDCP is a compliant with standards. Submit the DICE IDCP specifications as informational documents and potentially as basis for the protocol standardization effort.
Specifications and DocumentationImprove specifications and documentation to further facilitate others adopting and implementing.
Enhanced User Request Features/OptionsAdd additional user request parameters and features such as the ability to ask questions about what is possible without actually making a reservation. Or perhaps letting user make "loose" requests and responding back with options. This could also include extension of the ability to modify an existing reservation which is now limited to adjusting the end time.
Time Dimenstion SupportEnhance schemas to natively include the time dimension in the topology descriptions. There is more to this then just figuring out the needed schema changes. Since this would effectively add real-time topology information capabilities, there are lots of questions about how it would be utilized, and what some of the requirements might be for ensuring it is accurate and updated. This will need to be discussed further.
Advanced AAIDevelop a more sophisticated Authentication and Authorization feature set for the DICE IDCP. This topic has been discussed at the last few DICE meetings to leverage the EduGain based model of AutoBahn and PerfSonar. We noted that there is a DICE subgroup looking in to advanced AAI issues. We need to review that work, and determine what are the unique issues for the IDCP. These issues will likely revolve around the chaining model of reservation and provisioning in terms of associating the end-site user with middle domain policy application.
Multi-Layer SupportEnhance schemas and protocol documents to handle true multi-layer environments. Examples would be and end-to-end ethernet service which includes an interdomain link of a different technology such as SONET/SDH, MPLS, WDM, etc. It was noted that this feature may be more important for the GLIF community, where there are interconnects of technologies other then Ethernet. For the production networks, there seems to be more a general convergence on the use of Ethernet for network to network peering points. We also discussed some of the practical issues associated with allowing interdomain links to peer at technology layers other than Ethernet VLANS. This includes SONET/SDH vendor compatibility issues, and configuration issues (sts-1 vs sts-3 for example). We did not identify this as one of the higher priority items, but we should discuss this further, particularly in the context of GLIF Dynamic GOLE support, which is a very important capability we want to help facilitate.
Dynamic Provisioning with Protection/Resiliency/RestorationDevelop techniques and associated protocol features to enable the provision of multi-domain paths which have protection/resiliency/restoration features and capabilities. This feature does seem to be of interest, but was not identified as an immediate priority. This is more of a midterm issue.
Topology SharingDevelop an DICE IDCP automated multi-domain topology sharing and exchange mechanism. The PerfSonar inspired Topology Service performs this role for Internet2 and Esnet currently. However this is not an official part of the DICE IDCP. We had also discussed in the past other mechanisms for topology exchange. We should identify the DICE IDCP method for exchanging topology information. It was generally agreed that the DICE IDCP does not need to say too much about Topology Sharing. We will probably want to make sure we identify the message formats for an IDC to export and import topologies. From this we can work with others developing information distribution systems like the Topology Service to exchange the needed information.
Industry and Vendor Standards InteroperationEvaluate allowing industry standards mechanisms for signaling and user request to be incorporated into the overall DICE IDCP framework. The thought here are the mechanisms being developed by IETF, OIF, MEF such as RSVP based signaling and MEF defined services. This item was not identified as high priority.
Session Reservation ConceptThere may some benefits to decoupling the notion of a Reservation from a single circuit instantiation. The idea is that a reservation may create a "session" over which multiple circuits, or circuits with varying properties may be instantiated over time. This higher level session could then remain persistent over a larger time period, while individual instantiation parameters may change as needed. This may be similar to the current MODIFY operation, with a richer set of parameters and instantiations events which can be modified.
issue titleissue description
issue titleissue description
issue titleissue description
issue titleissue description
issue titleissue description