Coordinates

• http://www.ogf.org/gf/event_schedule/index.php?id=2104&tentative

Attending

• About 10-11 total.
  • Jason
  • Roman
  • Michael
  • Freek
  • Jerone
  • Richard
  • Inder
  • Chin
  • Some Tourists

Agenda

• Circuit Monitoring
• Advertising capabilities
• Streaming
• Slides: http://www.ogf.org/OGF30/materials/2104/20101028-JZ-NMCWG-2.ppt

Notes

Circuit monitoring.

Basic idea - Internet2/ESnet/Geant + other networks (soon RNP) will have dynamic circuit capabilities. Need a way to monitoring these. Could do it in one of two ways (simplistic view):

• Constant monitoring of all available interfaces/VLANs - correlation of the results after the fact (e.e. retrieve information from CP software in some manner...)
• Dynamic monitoring - receive information (pub/sub, or even constant poll) from the CP software. Learn where the circuit will exist. Monitor the necessary locations.
• Comment from Freek: could do it in a hybrid manner too.

(unstated) requirements:

• Use of the OGF work?
• NMC is the protocol of perfsonar - this is a given.
  • NM is the format of the data storage (e.g. utilization characteristic is the same for a dynamic circuit or an IP link - difference in layers only)
  • NML - desirable to use the latest schema. Represents a lot of work (would be the first implementation of the work in NML??). Don't want to rely on old CP topology if we can avoid it.

Status - DICE group (Internet2/ESnet/Geant + others) started an activity to explores this. Two proposals were discussed recently:

• perfSONAR-PS - Proposal takes into account perfSONAR-PS software and ION/OSCARS requirements
• MDM - Proposal was a JRA activity, and takes into account perfSONAR and AutoBAHN requirements
  • E2E mon backward compat not required.

Big Picture - different proposals emphasize some different things

• Some differences
• Some similarities
• Important piece of info - need interoperability at the schema and protocol levels - architecture may differ due to CP requirements.

• Protocol/Data/Topology descriptions
• role of the TS/LS
• "What is important about a circuit" - NSI ... can you hear us?
• Descriptors/IDs and why these matter to monitoring

!Protocols/Data/Topology Section:

Storage - easy. Use the NM formats for data representation. Storage within the implementation can be whatever makes sense (e.g. both implementations thing a relational DB works). Communication - derivatives of the current perfsonar protocols. Will involve IS messages, and MA messages (depends on the particular use case). Also not too hard Topology - the area where the proposals diverge.

• Ideal - NML topology (current is starting to stabilize - see NML notes for details, but there are no longer major changes between each meeting)
• Requirement - *must* have some common format between the CP frameworks
• pSPS proposal - modified version of current NML - would need to be polished a little bit. Also some open questions on things like relations and IDs.
• MDM proposal - based on AutoBAHN requirements. Did try to use 'current' pS topologies ... but ... the current thinking on topo was hard to find (2007 thoughts in the pS svn ... no real guidance beyond that)
  • ACTION - pS Devs need to talk more often, and clean up svn to make sure topology is well documented and available

• change each CP framework ... unlikely
  • Note - OSCARS .6 is being released in april 2011 ...
• Conversions between topo representations may work if there are differences

How will summarization of topology look in the hLS/gLS. Not really discussed in detail, but there are some things we need to consider:

• 'endpoints' of a circuit
• domains traversed by a circuit
• metrics available in each domain

!Role of the TS/LS

• TS as an LS - yes, it accepts registrations, queries, deletes. XML database backend.
• TS as an MA - 'topology' is the data for given domains (the domain as the '1st order' element?).

• Topology is different in each project.

MDM = cNIS still in use. Was not implemented in pS to start with (different model than pSPS topo). Use is more akin to a 'configuration service' - can be used to store details about devices (e.g. username/passwords for routers/switches - could be integrated into looking glass interface) Bottom line: need historical record of topology (lifetime elements) Ideas:

• May need a Joint Developer exercise to discuss the roll of topology in either project.
• Call the TS an MA?
• Call it an extension of the LS (and integrate it into the LS)
• Messages and use cases to support?

!"What is important about circuits"

We have some NSI people here - good! First lets care about IDs, two major styles:

• GLIF (e.g. urn:ogf:network:internet2.edu:STUFFSTUFFSTUFFSTUFF)
  • 'STUFF...' is opaque when exchanging, don't look at it!
  • 'STUFF...' has meaning in a domain (maybe)
• 'Other' - AutoBAHN has its own style, maybe some more out there

!IDs

Would really like to use what others have done ... no reinventing IDs GLIF works fine ... but there is the autobahn compat issue

The issue - IDs are important for being able to retrieve monitoring information about a circuit in each domain.

• retrieving individual segments (even if they are split in other domains)
• assuring that referring to a circuit by some name means that two parties would be sure you are discussing the same thing (e.g. global uniqueness)
• For example, if we supplied some ID to the monitoring MA in a domain, we would expect that the domain would know this circuit, and be able to tell us the segments that it knows about, and even relay the monitoring information it has.

Mechanical translation?

• AutoBAHN has internal IDs. Could pS provide a 'circuit service' that has the ability to translate between internal and external MAs (maybe even topology representation)
• Is this an LS (mdm proposal thinks so...)
• Is this an MA (jason thinks so :D)

!Wrap up on Circuits:

• Jason/Roman to summerize discussion and documents
• Report back to dice with some of the recommendations from here
• Next steps will be in that venue, but will update at OGF 31

Advertising capabilities:

Main idea is that there needs to be a change to the way the LS advertises things ServiceType - not really reliable ... user entered (e.g. MP)

• Client devs were using it, may not be the case anymore?

• e.g. I speak 'MP' protocol and 'MA' protocol

• use case - router at the border of a campus, one interface to the LHC facility, one to the LIGO facility

Streaming

XML encoding of large chunks of data may not make sense

• HADES needed a way to bulk transfer data - had a solution that involved
• FLOW MA was in a similar boat

• request message to initiate, response message to set up channel, **transfer**, stop reuest and ack message?

Discussion will go to the mailing list.