Hello,
I'm breaking our discussion out into two separate emails, because I would like to have some more participation in this particular issue. We need to identify the capabilities that NSI CS aims to have.
On 1 Dec 2011, at 00:44, Jerry Sobieski wrote:
> On 11/30/11 5:30 AM, Jeroen van der Ham wrote:
>> Hello,
>>
>> I think it's most important to identify the requirements that we have for the topology, and work from there:
>>
>> - We need to have some distribution method for topology
>> - This method must be maintainable for changes in the network, so it should allow updates.
>> - It must be possible to request a connection from port A with VLAN X to port B with VLAN X.
>> - It must be possible to request a connection from port A with VLAN X to port B with VLAN Y.
> The first two I am in agreement with. The second two I will argue are not real requirements of topology - they reflect some conventional notions of traditional signaling protocols and assume specific technology. Try to remember that the objective of NSI is to build *connections* - not VLANs per se. In NSI we have an abstracted model of a "connection" as a conduit for transporting payload data between two endpoints. These connections simply ride atop the infrastructure whatever it is. So the VLAN itself is not critical to NSI.
Note that I have specifically said that *NSI* must make it possible to do this. I did not say anything about the topology model, or the underlying service model.
The current reality is that (my estimate) 95% of connections over the GLIF network are built on top of VLANs. Bandwidth on Demand in Internet2, ESnet, and SURFnet are based on VLANs. The other 5% consist of timeslots and wavelengths, which are basically labels that have to be coordinated between adjacent networks as well.
If the NSI cannot support these kind of operations to begin with, we have a broken model and we will not get any adoption.
> I assert the following:
> - In an *ethernet* environment and traditional protocols you might expect this to be necessary, but its not a broad based requirement for NSI. We need to generalize the sentiment in order to keep the abstractions.
> - We *can* reserve a connection from a specific port and VLAN by associating the switch, port, vlan etc with and STP. As long as the RA somehow maps the VLAN to the STP then the RA places that STP as the endpoint. Simple. The CS protocol can do this.
>
True, but this comes at a certain cost. We need to identify the models and their associated cost in order to make an informed decision.
>>
>> Nice to haves:
>> - Dynamic availability information for both links and labels.
> As stated above, unless you have this "availability" information for your labels (or *any* termination point), you will end up guessing at their availability - which means you still have not solved the exhaustive search problem.
We cannot solve that problem since we are in a distributed environment. However, we can try to minimise its impact.
>> Do we also want to include a connection from port A to port B where you don't care about the label?
> This suggestion is not really a topology issue but a CS Protocol issue - it breaks the "specific endpoint" (point to point) semantics of the Connection request. Do you want a raw unlabeled connection? or a labeled connection but where you don't care which label? Will a stacked label be acceptable (e.g. QinQ)? What if the port is not a basic ethernet port, e.g. what if the port is a WDM port carrying many differnent colors each with different framing? What would you specify as the "endpoint" for a "Connection" request? If you don't care, then why can't the RA take the responsibility to simply select one regardless of the underlying labeling? And thus you leave it to the local NRM to engineer the connection internally to its network between the two *specific* endpoints requested by the RA. The easy answer here is to for the RA to not use tree segmentation at all but to specify a downstream endpoint and a chain request and let the local PF decide the local egress point.
The requirements I mentioned above were meant to get a feel for what the NSI connection service is trying to accomplish. Topology and Protocol will have to go hand in hand to solve this problem.
> - We also need a means of expressing basic abstract topological objects (e.g. nodes, ports, links, agents) that allows for recursive relational descriptions and maintains the strict technology agnostic abstractions NSI Framework requires, yet allows us to complement this basic ontology with enhanced detail - under local advertisement control of course. Remote PF implementations can leverage whatever detail is available to optimize the PF/Reservation process. Thoughts?
Abstraction is fine. The current GLIF DToX model is already an abstraction of a domain topology. I would rather have that it contains the internal transfer function as well, since that makes it easier for inter-domain pathfinding.
Jeroen.
