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 <jerry@nordu.net> Organization: NORDUnet To: John MacAuley <john.macauley@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...
- 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
O 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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg