[Nsi-wg] Encoding & Labeltype

John MacAuley john.macauley at surfnet.nl
Tue Nov 5 17:12:11 EST 2013 

Okay, I will bite!

What I am trying to do from a path finding perspective is take a detailed NML document and reduce it down to four objects: Network, TransferFunction, STP, and SDP in the context of each service request.  Therefore, if I get a service request for an EVTS serviceType I must be able to do path finding in the context of network resources supporting the EVTS serviceType.  In Madrid we agreed that we will associate a serviceType with an STP, so I can filter out all the STP not supporting the target serviceType.  This then lets me determine the applicable SDP.  So from a path computation perspective I have Networks (vertices) and SDP (edges) in my graph, however, this is not enough in that I also need the TransferFunction to determine if a Network can interconnect an ingress and egress SDP.  These are the basics of the NSI architecture.  I am not looking at any technology specifics.  I am just using the defined components of the NSI connection services architecture as defined by the collective brain trust :-)

Now comes the somewhat harder bit … How do I use the NML constructs to describe the NSI constructs of Network, TransferFunction, STP, and SDP in a correct and flexible way.  This has been the discussion on calls and e-mail over the last few weeks.

Here is what the group has almost agreed upon:

1. The NML Topology object maps to the NSI Network object.
2. The NML Port object maps to the unidirectional NSI STP object.
3. The NML PortGroup object maps to the underspecified unidirectional NSI STP object.
4. The NML BidirectionalPort object maps to both a bidirectional NSI STP object and an underspecified bidirectional NSI STP object.
5. The NML SwitchingService object maps to the NSI TransferFunction object.
6. For the NSI SDP object there are a number of NML objects available to do the modelling (Link and BidirectionalLink) but we are using the isAlias reference in the unidirectional Port/PortGroup to identify connectivity between networks.

Now I understand your argument 100% (or at least my filtered version of it).  I am building the simplified view you are looking for by using a more detailed NML view.  I end up treating STP as an abstracted string and grouping them in the transfer service as follows:

TransferService id="urn:ogf:network:netherlight.net:2013:topology:a-gole:testbed:evts" {
	urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1780
	urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1781
	urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1782
	urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1783
	urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:nordunet:1:vlan=1780
	urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:nordunet::1:vlan=1781
	urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:nordunet::1:vlan=1782
	urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:nordunet::1:vlan=1783
}

SDPs I create by concatenating their STP ids together:

SDP id="urn:ogf:network:uvalight.net:2013:netherlight:vlan=1796::urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1796" {
	urn:ogf:network:uvalight.net:2013:netherlight:vlan=1796
	urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1796
}

STPs are the standard networkId, localId, and labelType, but I make the id using local and label:

STP id="urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1780" {
	networkId = "urn:ogf:network:netherlight.net:2013:topology:a-gole:testbed"
	localId = "urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1"
	label (vlan = "1708")
	serviceType="EVTS.A-GOLE"
	directionality="bidirectional"
	other service related attributes …
}

And of course a network is a combination of all these:

Network id="urn:ogf:network:netherlight.net:2013:topology:a-gole:testbed" {
	List of TransferService
	List of SDP
	List of STP
}
	
I have created this NSI view of topology for my path finder to help prove or disprove the current definitions within the NSI architecture.  So far I have been able to do basic path finding, but we are only now drilling down into some of the technology hurdles we will face when trying to create this higher level abstraction.  Yes we are discussing the technology specific details in the context of NML, but we are trying to understand how it would be modelled in detail so we can understand what we need, and how it relates back to our abstractions.  Yes, I agree we could simply use NML to model no more than what we currently need in NSI, but I would like to make sure the standard if flexible enough to handle more detailed needs.

John 

On 2013-11-05, at 2:12 AM, Jerry Sobieski <jerry at nordu.net> wrote:

> 
> I really encourage everyone to think about this from the *service* perspective - i.e. what the network organization is willing to offering as a NSI service feature and what the users really *actually* want - Our NSI Services do not need to announce internal topology at all, nor do they need to express or incorporate every possible hardware capability.   Keep it simple (!!!)   A simple connection delivered to/from a STP associated with a VLAN tag.    You get into a lot of unnecessary topology munging by trying to expose and process every technical hardware capability.   Don't do this.  Its not necessary.   If you keep these topological details internal to a local NRM, then the announced topology is vastly simplified.     Let the NRM deal with details internally, but the inter-domain path finding should only need deal with *simple* contiguous services.    Don't try to make one NSI service capable of everything under the sun...doing so makes it too complex.  
> 
> Best regards
> Jerry
> 
> 
> 
> On 10/31/13 9:37 AM, Henrik Thostrup Jensen wrote:
>> Hi 
>> 
>> On Wed, 30 Oct 2013, Jeroen van der Ham wrote: 
>> 
>>> This is the decision regarding encoding and labeltype that was made for NML: 
>>> 
>>> https://forge.ogf.org/sf/sfmain/do/go/artf6577 : 
>>> 
>>>> NML has currently a one-to-one relation between the layer encoding (a URI to define the layer of sublayer of a specific Port of Link) and the label type (a URI to define the resource label of a technology). 
>> 
>> Make sense. Thanks for clarifying the difference. 
>> 
>> Right now we don't use the encoding in the NSI topology. Is this something we should consider? I am not entirely sure what the benefits are though. 
>> 
>>> There is not a one-to-one correlation, because encodings (such as Ethernet) still allow traffic without labels at all. 
>> 
>> Shouldn't a switching service have an encoding AND a labelType? An ethernet encoding could have both regular and VLAN and carrier ethernet vlan (with q-in-q / s-tag+c-tag), and might only be capable of changing one of them. How would I know which label types can be swapped? 
>> 
>> 
>>     Best regards, Henrik 
>> 
>>  Henrik Thostrup Jensen <htj at nordu.net> 
>>  Software Developer, NORDUnet 
>> 
>> _______________________________________________ 
>> nsi-wg mailing list 
>> nsi-wg at ogf.org 
>> https://www.ogf.org/mailman/listinfo/nsi-wg 
> 
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20131105/6e6b6392/attachment.html>

More information about the nsi-wg mailing list