[Nsi-wg] Service Termination Points

[Jerry Sobieski]

Hi John-
I know we've had long discussions about path objects.   But I am not so 
sure they are necessary...

If we can make two concatenated connections and treat them as one, then 
why do we need to specify loose hops?
We can instead just issue two reservation requests, right?   If so, this 
would substantially simplify the request structure.  And so far, I've 
not heard of any use case that multiple reservations would not work for 
transit routing.

??

Jerry


On 3/12/11 10:35 PM, John MacAuley wrote:
> Taking Jerry's definition and Tomohiro's note not to use domain or 
> endpoint I have defined the following three XML schema components:
>
>    1. A "Path Object Type" consists of at a minimum an "aSTP" and a
>       "zSTP", with an optional ordered list of "STP" defining the path
>       through the network.
>    2. An "STP Type" consisting of a mandatory "Network Id" string and
>       a mandatory "Local Id" string that uniquely identify the STP.
>        There is an optional "Order" attribute that will only be
>       populated when the STP is part of the ordered list.
>    3. An "STP List Type" that will support both an ordered and
>       unordered list of STPs.
>
>
> So is does my definition of a Path Object cover what was intended in 
> the CS architecture document?
>
> <xsd:complexTypename="PathObjectType">
> <xsd:sequence>
> <xsd:elementname="aSTP"type="tns:StpType"minOccurs="1"maxOccurs="1"/>
> <xsd:elementname="orderedStpList"type="tns:StpListType"/>
> <xsd:elementname="zSTP"type="tns:StpType"minOccurs="1"maxOccurs="1"/>
> </xsd:sequence>
> </xsd:complexType>
>
> <xsd:complexTypename="StpType">
> <xsd:sequence>
> <xsd:elementname="networkId"type="xsd:string"minOccurs="1"maxOccurs="1"/>
> <xsd:elementname="localId"type="xsd:string"minOccurs="1"maxOccurs="1"/>
> </xsd:sequence>
> <xsd:attributename="order"type="xsd:integer"/>
> </xsd:complexType>
>
> <xsd:complexTypename="StpListType">
> <xsd:sequence>
> <xsd:elementname="stp"type="tns:StpType"minOccurs="0"maxOccurs="unbounded"/>
> </xsd:sequence>
> </xsd:complexType>
>
> On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote:
>
>> Hi John-
>>
>> Yes.   For NSI I think we can say an STP==endpoint.
>>
>> I think STPs in the abstract sense may be topological locations other 
>> than just a port or a VLAN, but for the purposes of NSI v1.0, I think 
>> a "real STP" is indeed a location in the topology where a connection 
>> may originate or terminate.
>>
>> (I note that I used a circular reference in the endpoint definition.  
>> Apologies.  An Endpoint is the physical topological terminus of a 
>> connection.)     I do reserve some flexibility in the abstraction 
>> however.  I think there are ways we can use Service Termination 
>> Points to indicate larger complexes of topological elements.   If 
>> folks are intersted I will elaborate, but for now, and to be 
>> expedient with respect to defining ReserveRequest() parameters, I 
>> suggest we accept an adequate definition and leave additional 
>> refinement to later.
>>
>> Is this helpful?
>> Jerry
>>
>> On 3/12/11 9:57 PM, John MacAuley wrote:
>>> Jerry,
>>>
>>> So based on your definition below is STP == Endpoint Reference from 
>>> an NSI protocol perspective?
>>>
>>> Definitions:
>>>
>>> *Service Termination Point*:= 1. An abstract object that represents 
>>> the ingress or egress point of a connection, or the abstract notion 
>>> of a location in a topology where a connection could potentially 
>>> originate or terminate.2. A real point in a topology where a 
>>> connection can originate or terminate.
>>>
>>> *Endpoint *:= In NSI, this is a location within a network that can 
>>> be used as an endpoint for a connection.
>>>
>>> *Endpoint Reference*:= a two-tuple consisting of a {<network name>, 
>>> <endpoint name>} .An “endpoint reference” is this tuple, the 
>>> “endpoint” itself is the topological location it identifies.
>>>
>>>  John.
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110312/c9d6b2e4/attachment-0001.html