[Nsi-wg] Service definitions (draft) for Point-to-Point Ethernet

[Henrik Thostrup Jensen]

Hi everyone

Here are high-level descriptions of suggested ethernet service 
definitions.

These are the result of a conversation that Jerry and I had some weeks 
ago, along with the latest discussions on the calls. The definitions are 
fairly close to what we already had, but are more precise and involve some 
more ethernet specific attributes.

There are two suggestions here. One for plain ethernet, and one for vlan 
over ethernet. Organizing the the request types / service definitions like 
this makes it very clear what is going, but is also slightly less flexible 
than what we previously had, e.g., there is no clear way for how to 
provide a connection where one end is plain ethernet and the other is on a 
VLAN. However, as the point here is interdomain, I think simplicity is a 
virtue, and I don't see it as a major loss.

The order of in which the attributes are listed is largely random.


Point-to-Point Ethernet (suggested short name ets_v1)

* Directionality    := choice(Bidirectional, Unidirectional).
                        Optional, default: Bidirecitonal
   Specifies if the circuit should only carry data in one direction or in
   both direction. If Unidirectional, data can only be carried from source
   to destination.

* Symmetric         := Boolean. Optional. Default: False
   Can only be specified for bidirectional circuits.
   If true, the circuit creates must follow the same path in both
   directions.

* Source STP        : PortType (network + port). Mandatory.
   Specifies the source of the data flow.
   Network+Port values are similar to current STP constructio.

* Destination STP   : PortType (network + port). Mandatory.
   Specifies the destination of the data flow.
   Network+Port values are similar to current STP constructio.

* Capacity          : Integer. Mandatory.
   Specifies the required capacity of the circuit. In Mbps.
   The capacity includes ethernet framing headers (because thats what
   Ethernet does)

* MTU               : Integer. Optional.
   Specifies the maximum transmission unit size. In bits.

* Burstsize         : Integer. Optional.
   Specifies the maximum number of bits that can be send to the interface
   before the sender must wait before sending again.

Point-to-Point Ethernet VLAN (suggested short name evts_v1)

# Includes the same attributes as the Ethernet service.

* Source VLAN       : Integer (1-4095). Mandatory.
   Specifies the VLAN for the source port.

* Destination VLAN  : Integer (1-4095). Mandatory.
   Specified the VLAN for destination port.


I suggest not having any ANY elements or similar in these, as they are 
strict thingies.



* Service types and Topology

Where this gets interesting, is how the service definitions mix up with 
the topology. At the very least we need a way to announce which service 
types a NSA or Network (Topology in NML lingo). I'm a bit unsure how to 
structure this. Just because an NSA supports a request type, doesn't mean 
that the network can provide it and vice versa. However IMHO it only makes 
sense to announce service types, which the NSA AND Network can provide. 
However an NSA may adminstrate multiple networks, which shakes things up a 
bit. I am unsure if it should be attached to the network, but leaning 
toward the network.

Another thing to consider is if how match the service types and ports in 
the topology. One option is to have a mapping between labels and service 
types, or simply just list the service types on the ports. This would make 
it clear which ports could support features like jumbo frames (by having a 
large mtu capability). This could even be necessary for path finding.

The idea of listing capabilities in the topology like this is somewhat 
different than the core principles in NML, which is more geared towards 
describing network a link and labels (plumming so to say), where using 
service definitions it becomes more oriented towards capability.

The capability oriented approach could have some advantages in topology 
aggregation / scaling, where a network could announce reachability to 
other networks in terms of capability, i.e., nordunet can provide transit 
to surfnet on ethernet with the following parameters, etc. This is a lot 
more useful than just reachability, and compresses quite well.

Thoughts?


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet