[Nsi-wg] Fwd: Re: comments to WSDL files

Thu Apr 7 02:51:52 CDT 2011

Hi,

I agree NSI to be kind of technology agnostic, but we need to have also functionality in sight. In some cases users don’t care, as they get dedicated physical ports and whatever is terminated there is transparent. In some cases however a VLAN will be important for them, and moreover they would like to specify this VLAN or at least allowed range. There need to be a way to do such things. This will also escalate to PBT, PBT-TE and PBB, and to other non-Ethernet based technologies where you will need to specify various technology specific stuff. In AutoBAHN we started with pure technology agnostic approach and leaving every technical details to be configured by a network itself (i.e. VLAN ID). The requirements here has changed rapidly due to user requirements, and we need to support VLAN ID selected by a user. IMHO STP is fine to determine connection endpoint, but insufficient to request a service in some cases. An additional attributes for the STP are required sometimes.

Best regards

Radek

________________________________________________________________________

Radoslaw Krzywania                      Network Research and Development

                                           Poznan Supercomputing and  

 <mailto:radek.krzywania at man.poznan.pl> radek.krzywania at man.poznan.pl                   Networking Center

+48 61 850 25 26                              <http://www.man.poznan.pl> http://www.man.poznan.pl

________________________________________________________________________

From: nsi-wg-bounces at ogf.org [mailto:nsi-wg-bounces at ogf.org] On Behalf Of Jerry Sobieski
Sent: Wednesday, April 06, 2011 7:39 PM
To: nsi-wg at ogf.org
Subject: [Nsi-wg] Fwd: Re: comments to WSDL files

I should have replied-all...
J

-------- Original Message -------- 

Subject: 

Re: [Nsi-wg] comments to WSDL files

Date: 

Wed, 06 Apr 2011 13:28:04 -0400

From: 

Jerry Sobieski  <mailto:jerry at nordu.net> <jerry at nordu.net>

Organization: 

NORDUnet

To: 

John MacAuley  <mailto:john.macauley at surfnet.nl> <john.macauley at surfnet.nl>

NSI is not VLAN sensitive...this is soo hard for people to grip.   In 
NSI, we specify "connections" across "network", between two 
"endpoints".  Period.  Its *that* simple.
If that requires that we have 4000 entries in our topology DB 
representing VLAN endpoints across the ENNI, so be it...its a topology 
problem -not an NSI CS problem.   Its a pathfinder problem, not a 
ReserveRequest problem.

An NSA for network "netA" gets a request netA:F>netQ:M,  the NSA looks 
at the orig netA:F and knows its in his own network.   NSA looks at dest 
netQ:M and realizes its in a remote network.   NSA calls the pathfinder 
to select an exit point from netA:F towards netQ:M.  Pathfinder says go 
to netB:io1 next via netA:x10.    NSA creates a segment netA:F>netA:X10, 
it looks up netA:F in local topoDB and build a hdw request from 
"sw=F10-e300 port=3/2 vlan=27" he found from the topoDB, he looks up 
netA:X10 in topodb and come up with hdw info"sw=dell3236 port=1/1 
vlan=2998" he puts both hardware endpoints in the NRM reserve request 
and  and passes the nrm request to local NRM.  Local segment done.     
NSA then goes to pathfinder again to ask:  next hop for netB:io1 > 
netQ:M  (this is tree)   Pathfinder says netC:i1 next via netB:io9.  NSA 
build SR for netB:io1>netB:io9 and sends to netB NSA.   NSA then goes to 
PF from netC:i1>netQ:M.  PF return NetD:in via netC:o9...  This 
continues until a segment is built for the last network.   In this 
process, each NSA gets a request with only local endpoint STPs, the NSA 
will see both are local, and will build a local nrm request with 
hardware specs just as the first hop NSA did.

Alternately, after the first hop NSA does his local ReservationRequest, 
it can build a SR for netB:io1>netQ:M and submit it to netB NSA.  If a 
confirm comes back, we have a circuit. (this is chain)

does this help?

j

On 4/6/11 9:35 AM, John MacAuley wrote:
> Taking time off from the NSI the last couple weeks has muddled my head.
> 
> Taking the current Automated GOLE demo service as an example, we specify a VLAN to provision across the network and the E-NNI Ethernet edge ports along the path.  Are you saying that we no longer do this and that an STP would reference pre-defined VLANs?  I am having problems visualizing.
> 
> Thanks,
> John.
> 
> On 2011-04-06, at 12:27 AM, Jerry Sobieski wrote:
> 
>> Not quite, John.  The STP (<net>:<ep>  tuple) should be considered to be a link into the local topology db.   The physical specifics of the termination point are found there- not in the service request.
>> 
>> When processing the SR, the NSA will look up the network in the topodb and find a path to that network.   At some point, a segment will be generated from the far network edge to the end point and set to the NSA.  That NSA will realize the endpoints are local, and will know then to convert the NSI tuples to NRM nomenclature and any other munging about of the SR.   The NSAs will need a local internal mechanism to map NSI names to local physical specifications for the NRM.  That might be a look up name table, or it may be a name list in the topology DB that has the NSI name associated with a topology object.  In any case, the topology object should have information relating to the termination point details - vlan tag, port, switch, availbale cap, etc.
>> 
>> The VLAN tag is NRM specific information and is not recognized by NSI.   Unless we elect to define VLANs in the Service Definition, they won't either show up in the ReserveRequest.    All the specific hardware information is found in the topology DB.  The local NRM topology DB will say if the termination point is a tag on a port on a switch... or is just a port on a switch (or tag0 on a port on a switch).
>> 
>> The user doesn't know and should have to know the technical specs associated with an far STP in some remote land.   The request simply specifies an STP - the networkname:endpointname tuple.  The request will specify the bandwdith, orig and dest STP, and other parameters defined in the Service definition.     The primitive does not have guaranteed attributes...(I saw these in the xsd...  What are those?)
>> 
>> j
>> 
>> On 4/5/11 10:45 PM, John MacAuley wrote:
>>> So based on the discussion here, have we answered Radek's original request with respect to VLAN against the ServiceTerminationPointType?
>>> 
>>> In my mind the answer is that the  ServiceTerminationPointType identifies the abstract interconnects, while specifics of the service are held in the ServiceParametersType.  The tagged/untagged and specific VLAN id would be populated in the "guaranteed" attribute sequence as per the service definitions.
>>> 
>>> John.
>>> 
>>> On 2011-03-29, at 3:13 PM, Jerry Sobieski wrote:
>>> 
>>>> Oops - one thing I should make clear below...
>>>> 
>>>> O
>>>>>> - In ServiceTerminationPointType, it would be useful to have information whether port is tagged or not (VLANs information is not stored also). I know that we would like to keep the messages as technology agnostic as possible, but we need to have a balance between functionality and simplicity/universality here. In case of AutoBAHN we can probably do some workarounds to evade the issue, however this is not plug-and-play ;)
>>>>> Hej Radak-
>>>>> 
>>>>> The STP is just an NSI name.<network>:<localname>       NSI does not
>>>>> encode any physical topology information into the name.  It is just a
>>>>> name.  I expect the NSA would use the name to index into a table of
>>>>> local names to link to the local topologyDB. (Alternatively, the NSA may
>>>>> simply search the local TopoDB for a topology object with this NSI name.
>>>>> ...but this is all an implementaion detail)   The topoDB would indicate
>>>>> whether that STP maps to a port or VLAN or something else.  Since NSI
>>>>> does not define any technology specific topology information, things
>>>>> like VLANs and ports etc are only of significance to the local NRM
>>>>> (AutoBahn in this case).   And it becomes the responsibility of the NRM
>>>>> (AutoBahn in this case) to provide a translation from the NSI local
>>>>> endpoint name to any NRM specific denotion.  (Also, since each NRM is
>>>>> different, it would be impractical for the NSA to know each dialect of
>>>>> every NRM it might encounter...)
>>>> The *service* specifics - things like bandwidth or MTU or other service
>>>> related specifics of a particular connection service are defined in the
>>>> Service Definition.  The ReservationRequest contains such service
>>>> attributes, and they are qualified against the Service Definitions of
>>>> the transit networks, but they are not specifically part of the NSI-CS
>>>> protocol.
>>>> 
>>>> We have tried to separate the service specifics from the protocol(s)
>>>> that communicate them.   The NSI-CS protocol recognizes an abstract
>>>> model of a "connection", but hardware specifics of a particular
>>>> connection service offering or a particular service instance are not
>>>> hard wired into the NSI-CS protocol.  This will allow a great deal of
>>>> flexibility to map multi-layer and heterogenous connection services and
>>>> their dialects to the same generic and global protocol framework.
>>>> 
>>>> Hope this helps a bit more..
>>>> J
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> nsi-wg mailing list
>>>> nsi-wg at ogf.org
>>>> http://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110407/e64817f4/attachment-0001.html 