| 1 | [[PageOutline]] |
| 2 | |
| 3 | = GENI Shadownet Project Status Report = |
| 4 | |
| 5 | Period: Post GEC 11 Report |
| 6 | |
| 7 | == I. Major accomplishments == |
| 8 | |
| 9 | The following highlights our accomplishments |
| 10 | during the last reporting period. |
| 11 | |
| 12 | === A. Milestones achieved === |
| 13 | |
| 14 | During the last reporting period we achieved the following milestones: |
| 15 | * (milestone s3.c) We took a major step toward making Juniper routers |
| 16 | accessible |
| 17 | to GENI users by integrating our Shadownet Component Manager into the |
| 18 | ProtoGENI control framework so that the logical routers on the Juniper |
| 19 | will appear as resourses available for users to use. Our next step is to |
| 20 | integrate our instrumentation tools with the Juniper routers so that |
| 21 | monitoring/measurement data collection is setup automatically -- in our |
| 22 | previous demos this was a manual process. |
| 23 | * (milestone s3.d) We updated our Shadownet web pages with information |
| 24 | about the system and support contacts for the Shadownet Aggregate. |
| 25 | * (milestone s3.e) We have an initial design and implementation of |
| 26 | our software that works in conjunction with the perfSONAR tools. |
| 27 | |
| 28 | === B. Deliverables made === |
| 29 | |
| 30 | * Routers have been installed and are being operated in all four |
| 31 | Shadownet locations: Kansas City, Salt Lake City, Washington DC, and |
| 32 | Atlanta. |
| 33 | |
| 34 | == II. Description of work performed during last quarter == |
| 35 | |
| 36 | The following provides a description of the progress made during the last |
| 37 | reporting period. |
| 38 | |
| 39 | |
| 40 | === A. Activities and findings === |
| 41 | |
| 42 | Our work this past quarter focused on the problem of integrating Shadownet |
| 43 | into the ProtoGENI network with the intent of making the GENI Shadownet |
| 44 | resources available via the ProtoGENI interfaces and APIs. Starting with the |
| 45 | standalone GENI Shadownet CM (component manager) |
| 46 | that we developed earlier, we made modifications in order to integrate |
| 47 | it into the ProtoGENI architecture, enabling it to accept |
| 48 | ProtoGENI credentials and interact with ProtoGENI users via the standard |
| 49 | ProtoGENI API calls. We developed our initial version of the system in a |
| 50 | test environment in order to evaluate our design and implementation. |
| 51 | Recently, we moved our GENI Shadownet CM from the test |
| 52 | environment to the production ProtoGENI network. We have now integrated our |
| 53 | CM with the ProtoGENI Clearinghouse which means that all |
| 54 | the resources advertised by our component manager automatically become visible |
| 55 | to GENI users and can be allocated by them into their slices. For example, |
| 56 | users of the ProtoGENI FLACK client are now able to see the Shadownet CM |
| 57 | and any resources that it has been configured to advertise. |
| 58 | |
| 59 | One of the key issues we have been working through is the issue of how to |
| 60 | connect the Juniper's logical router interfaces to other ProtoGENI routers |
| 61 | and end systems (say nodes at Kentucky or Utah). |
| 62 | Because these resources are often managed by other CMs, connecting to these |
| 63 | resources involves "stitching" together resources from the Shadownet CM |
| 64 | with end system nodes advertised by, say, the Utah or Kentucky CMs. |
| 65 | While there has been siginificant progress this past year in regards |
| 66 | to stitching in GENI, it is still a work in progress with several limitations. |
| 67 | Given the fact that stitching is not yet mature, we have begun to look at |
| 68 | other options for connecting our logical routers to other GENI resources. |
| 69 | We are currently exploring a solution based on GRE tunnels since GRE tunnels |
| 70 | represent a "least common denominator" across a wide range of GENI resources. |
| 71 | Ideally, one would like |
| 72 | each logical router to have its own unique, |
| 73 | routable, IP address. However, as of this writing, we do not have |
| 74 | enough IP addresses to give away to logical routers. |
| 75 | Consequently, we have been looking into ways to run GRE tunnels over a single |
| 76 | shared IP address used by the physical router. We have had some success |
| 77 | doing this in a test environment, but are still working on getting this |
| 78 | working in the more general ProtoGENI environment. In the meantime, we have |
| 79 | initiated discussions with our colleagues at Internet 2 about obtaining |
| 80 | additional IP addresses which would greatly help, and we continue to be |
| 81 | involved in the stitching discussions. |
| 82 | |
| 83 | We also made significant enhancements to our GENI Monitoring Portal (GMP) |
| 84 | interface and |
| 85 | integrated the portal interface with the ProtoGENI FLACK graphical user |
| 86 | interface so that users can get directly to the portal from the FLACK |
| 87 | interface. The portal shows the location of the resources that comprise a |
| 88 | slice on a map and provides a link for users to immediately view measurement |
| 89 | data being gathered at nodes and links as well as providing a link that will |
| 90 | take the user to the measurement controller associated with a set of |
| 91 | resources. Part of our enhancements have focused on redesigning the portal to |
| 92 | be able to interact with the measurement controllers for the shadownet logical |
| 93 | routers. Our current plan is to allocate multiple measurement controllers, |
| 94 | one for each of the shadownet routers to be monitored. This differs from the |
| 95 | single MC per aggregate approach we have used to-date, but enables us to |
| 96 | localize data communication so that it does not leave the Internet 2 backbone |
| 97 | until the user requests that it be archived. We also modified our portal |
| 98 | server to support both RSPEC v1 and v2 specifications, extracting and |
| 99 | displaying the topology information embedded in these RSPECs. |
| 100 | We also added the ability to view the |
| 101 | topology/resources at various zoom levels, making it easier for users to get |
| 102 | at the data they wish to observe. |
| 103 | |
| 104 | During this time, we also continued to support and operate the Juniper routers |
| 105 | in the Internet 2 backbone, and have been using the routers in our testing |
| 106 | and evaluation of the new Shadownet CM. |
| 107 | |
| 108 | Finally, we continue to have discussions with the PerfSONAR team to |
| 109 | better understand how we can more tightly integrate the data collection from |
| 110 | our logical routers with PerfSONAR. |
| 111 | |
| 112 | === B. Project participants === |
| 113 | |
| 114 | The following individuals are involved with the project in one way or another: |
| 115 | * Jim Griffioen - Project PI (Kentucky) |
| 116 | * Zongming Fei - Project Co-PI (Kentucky) |
| 117 | * Kobus van der Merwe - Project Co-PI (AT\&T) |
| 118 | * Eric Boyd - Subcontract Lead (Internet2) |
| 119 | * Brian Cashman - Network Planning Manager (Internet2) |
| 120 | * Lowell Pike - Network administrator (Kentucky) |
| 121 | * Hussamuddin Nasir - Technician/Programmer (Kentucky) |
| 122 | * Charles Carpenter - Researcher/Programmer (Kentucky) |
| 123 | * Emmanouil Mavrogiorgis - Research Staff (AT\&T) |
| 124 | |
| 125 | === C. Publications (individual and organizational) === |
| 126 | |
| 127 | === D. Outreach activities === |
| 128 | |
| 129 | === E. Collaborations === |
| 130 | |
| 131 | Most of our collaborations have been with the Shadownet team. In particular, |
| 132 | it involves participants from Kentucky, |
| 133 | AT\&T, and Internet2, but we have also had several conversations |
| 134 | with our ProtoGENI and perfSONAR colleagues. |
| 135 | |
| 136 | === F. Other Contributions === |
| 137 | |