Stitching details for AM developers¶
Stitching is a highly complicated subject. Please contact us first for some pointers before proceeding with implementing it!
“Stitching” and “Dedicated Ext. Network Connection” are both methods to connect testbeds using dedicated physical links. Thus a fixed delay and bandwitdh is available between nodes.
An alternative to both is to connect nodes over the internet, but this only offers “best-effort” delay and bandwidth (this typically uses “virtual links”, created gre-tunnels or other methods).
“Real” Stitching: automated multiple hops and VLAN translation¶
Stiching is used to create links between different AMs and testbeds. The user just draws a link between 2 nodes of a different testbed in the jfed experimenter GUI. Behind the scenes, VLAN connections are setup over dedicated link(s) between the different testbeds. Possibly, the testbeds are not directly connected, and a few hops are needed to make the connection. On each of these hops, VLAN translation may be required to change to the VLAN used in the next link. Each involved AM must keep track of the used VLANs on each external link.
The user does not need to know any of these details, but the client software needs to send VLAN info to each VLAN, and work as an intermediate to find a working configuration.
To start this setup procedure, the client first needs to contact the SCS: the “Stitching Computation Service”. This service has info on the interconnections between all AMs, so it can find a path from AM to AM, passing though the needed AMs on the way. The client needs receives info from the SCS about which AMs to contact in which order.
The SCS will then request the advertisement RSpec of the AMs periodically. To allow stitching, the advertisement RSpec must contain info about external links.
At imec/iMinds we run an SCS at http://scs.atlantis.ugent.be:8081/geni/xmlrpc There is also a geni SCS. The SCS’s must be configured with info about the AMs that offer external links.
Stitching is a very complicated topic. Here are a few points that might be good to know:
The SCS is needed, because in some cases, a stitched link that goes from one AM to another, will actually cross one or more other AMs. Only the central SCS can know about this topology, as it talks to all involved AMs. It is this topology information that the SCS will send to clients.
You can run your own SCS, and jFed can be configured to use this specific SCS for specific testbeds. However, it’s probably easier and better in the long run if we just add the info to our SCS.
The advertisement RSpec contain extra information in related to stitching. This information is in a seperate namespace. See the example below.
The SCS gets a request RSpec as input, and appends stitching information to it. This request RSpec is then sent to each involved AM.
The manifest RSpec contains cross-AM info about the current stitching setup.
There is a special error code and message that AMs should return for failures related VLANs not available for stitching.
There are 2 important features that improve stitching setup time:
- Support for “any” VLAN in the request RSpec: instead of specifying a VLAN, the client is allowed to set the special keywork “any” instead, and let the AM choose
- Up to date advertisement RSpecs: The advertisement RSpec always contains up to date info on which VLANs are currently available.
The client code in the jFed experiment GUI that manages stiching is very complex, to handle all cases. The client must “negotiate” between the different AMs until a stitching configuration ( = which VLANs on which AM) is found that works on all AMs.
Below is an extract from the wall2 stitching info in the advertisment request:
<stitching lastUpdateTime="2017-02-15T06:19:30Z" xmlns="http://hpn.east.isi.edu/rspec/ext/stitch/0.1/"> <aggregate id="urn:publicid:IDN+wall2.ilabt.iminds.be+authority+cm" url="https://www.wall2.ilabt.iminds.be:12369/protogeni/xmlrpc/am"> <aggregatetype>protogeni</aggregatetype> <stitchingmode>chainANDTree</stitchingmode> <scheduledservices>false</scheduledservices> <negotiatedservices>false</negotiatedservices> <lifetime id="life"> <start type="time">2017-02-15T06:19:30Z</start> <end type="time">2017-02-15T06:19:30Z</end> </lifetime> <node id="urn:publicid:IDN+wall2.ilabt.iminds.be+node+c300b"> <port id="urn:publicid:IDN+wall2.ilabt.iminds.be+stitchport+c300b:4.2"> <capacity>1000000</capacity> <maximumReservableCapacity>1000000</maximumReservableCapacity> <minimumReservableCapacity>1000</minimumReservableCapacity> <granularity>1</granularity> <link id="urn:publicid:IDN+wall2.ilabt.iminds.be+interface+c300b:4.2"> <remoteLinkId>urn:publicid:IDN+wall1.ilabt.iminds.be+interface+c300a:4.1</remoteLinkId> <trafficEngineeringMetric>10</trafficEngineeringMetric> <capacity>1000000</capacity> <maximumReservableCapacity>1000000</maximumReservableCapacity> <minimumReservableCapacity>1000</minimumReservableCapacity> <granularity>1</granularity> <switchingCapabilityDescriptor> <switchingcapType>l2sc</switchingcapType> <encodingType>ethernet</encodingType> <switchingCapabilitySpecificInfo> <switchingCapabilitySpecificInfo_L2sc> <interfaceMTU>1500</interfaceMTU> <vlanRangeAvailability>197,300-349,750-1000</vlanRangeAvailability> <vlanTranslation>false</vlanTranslation> </switchingCapabilitySpecificInfo_L2sc> </switchingCapabilitySpecificInfo> </switchingCapabilityDescriptor> </link> </port> ....
Stitching alternative: Dedicated Ext. Network Connection¶
If you only need single hop stitching, you can make things easy, by using links to fake nodes, which represent certain VLANs. The disadvantage is that this is less transparant for end users. It is however, much easier to implement on the AM.
In the jFed GUI, this is implemented with the “Dedicated Ext. Network Connection” icon. You drag in this icon, and then make a link between a real node and this “virtual” node.
TODO: add an example of this.