Here are some thoughts on what a "Path Object" (PO) should contain and/or be able to do...please read thru and think about this and let me know your thoughts. Jerry - A Path Object is an ordered list of service transit points (STPs) through which a connection passes. - A Path Object must have at least two STPs: The ingress STP, and the egress STP. - A Path Object should allow a path to be described using "sub-paths" (i.e. other Path Objects) or pointers/tags that reference other Path Objects. - A Path Object is direction sensitive. I.e. The path is always interpreted as beginning at the first STP (the head of the list), and proceeding towards the last STP (the tail) in the list. There is no implication that a path object is reversable (or bidirectional). - A "fully specified" path identifies the complete set of STPs - in order - that a connection transits from ingress to egress. - A "partially specified" path identifies a subset of STPs - in order - that the connection transits - but not necessarily every STP the connection transits. THis is a "loose hop" path - A partially specified path may contain STPs that are, individually, only partially specified. For example, a path may contain a STP indicating a specific switching element to be transitted, without specifying the specific port or VLAN id to be used. This could also be generalized to indicate something as general as an particular network to be transitted. Alternatively, the path element may specify a "label set", i.e. a set of labels or STPs that can are acceptable within the context of that STP. THis may be useful for conveying valid VLAN IDs or Wavelengths that may be available to path selection functions downstream or for end-to-end tagging information. Path objects can be used in several ways: First, would be to specify constraints on a *proposed* path - i.e. must transit this switch, but port selection has full freedom. Or must transit this previously defned path. The path objects need wild card masks to indicate these constraints. Second use is to define a connect "as built", i.e. after the cnnection is full specified and/or in service, a fully specified detailed Path Object would capture the entire detailed path - end-to-end but perhaps not fully exposed. BNF format: <Path_Object> := <Path_Object_Header> <Path_List> <Path_List> := <STP> ( <Path_Object> | <STP> ) + | <Path_Object>+ Path elements can be STPs or Path Objects. STPs represent topology locations, these will likely be something such as: <domain_identifier><pointID> or <dom><node><port><label><...>. These will likely be alphanumeric strings, possibly parsable, or they may be binary structures... Likewise with Path Objects - these will likely be something like <domain><objectID>. The key concept however is that the Path Object contains two types of elements: service termination points that refer to points in the topology, and a path object tag that refer to another strucutre outside the current path object. So each elemnt of the path list must have a type code to say what type of path element it is, and then a string to uniquely dentify that object within a local context, and a length that says how long the object tag is.
This is very good - thank you very much. Some comments in line -- except one here -- I like the name CTP rather than STP. A major reason is that this is on the transport plane, not the service plane, and calling it service termination seems to me to imply service plane. I leave this discussion to later as it doesn't affect the meat of the discussion. On Jan 20, 2010, at 2:24 PM, Jerry Sobieski wrote: > Here are some thoughts on what a "Path Object" (PO) should contain > and/or be able to do...please read thru and think about this and let > me > know your thoughts. > > Jerry > > > > - A Path Object is an ordered list of service transit points (STPs) > through which a connection passes. > > - A Path Object must have at least two STPs: The ingress STP, and the > egress STP. > > - A Path Object should allow a path to be described using "sub-paths" > (i.e. other Path Objects) or pointers/tags that reference other Path > Objects. - are there existing examples of this or is it a proposal? > > - A Path Object is direction sensitive. I.e. The path is always > interpreted as beginning at the first STP (the head of the list), and > proceeding towards the last STP (the tail) in the list. There is no > implication that a path object is reversable (or bidirectional). > does this have to do with pathfinding or is there something more to it? > - A "fully specified" path identifies the complete set of STPs - in > order - that a connection transits from ingress to egress. > are these STPs for all resources in the path that are controlled by different NRMs > - A "partially specified" path identifies a subset of STPs - in > order - > that the connection transits - but not necessarily every STP the > connection transits. THis is a "loose hop" path > > - A partially specified path may contain STPs that are, individually, > only partially specified. For example, a path may contain a STP > indicating a specific switching element to be transitted, without > specifying the specific port or VLAN id to be used. This could also > be > generalized to indicate something as general as an particular > network to > be transitted. Alternatively, the path element may specify a "label > set", i.e. a set of labels or STPs that can are acceptable within the > context of that STP. THis may be useful for conveying valid VLAN > IDs or > Wavelengths that may be available to path selection functions > downstream > or for end-to-end tagging information. > > Path objects can be used in several ways: First, would be to specify > constraints on a *proposed* path - i.e. must transit this switch, but > port selection has full freedom. Or must transit this previously > defned > path. The path objects need wild card masks to indicate these > constraints. Second use is to define a connect "as built", i.e. > after > the cnnection is full specified and/or in service, a fully specified > detailed Path Object would capture the entire detailed path - end-to- > end > but perhaps not fully exposed. > I agree with this, but perhaps defining what is "required" and what is "allowed" , especially in situations where a connection is made from multiple RMAs in different provider agents. > BNF format: > > <Path_Object> := <Path_Object_Header> <Path_List> > > <Path_List> := <STP> ( <Path_Object> | <STP> ) + | > <Path_Object>+ > > Path elements can be STPs or Path Objects. STPs represent topology > locations, these will likely be something such as: > <domain_identifier><pointID> or <dom><node><port><label><...>. These > will likely be alphanumeric strings, possibly parsable, or they may be > binary structures... Likewise with Path Objects - these will likely > be > something like <domain><objectID>. The key concept however is that > the > Path Object contains two types of elements: service termination points > that refer to points in the topology, and a path object tag that refer > to another strucutre outside the current path object. So each > elemnt of > the path list must have a type code to say what type of path element > it > is, and then a string to uniquely dentify that object within a local > context, and a length that says how long the object tag is. > So, for something like the chain model where segments A-B-C are included. Typically provider A gets request, inludes ingress and egress of A in the path and forwards the path in a request to B. I think the ingress and egress of A need to be either dropped or marked as "not part of the request to B". I think this might be done explicitly or by implication, but would be good to define. John > > > > _______________________________________________ > nsi-wg mailing list > nsi-wg@ogf.org > http://www.ogf.org/mailman/listinfo/nsi-wg
Thanks Jerry, it's a thorough description! Nevertheless, the definition of STPs is not 100% clear to me, and I understand John's concerns regarding this. As you described, Jerry, STPs may be understood as "pointers" to the service interface of the entities (NSA) that are in charge of the path. In other words, the URL or Service ID of the NSAs, which in any case belong to the service plane, rather to the transport plane. I'm not against this, on the contrary, I agree to have STPs in the PO definition. In this case, the PO shows also a list of service entities along the path. At this point I wonder if the PO is the service plane equivalent of the ERO on the data/transport plane. Obviously, PO and ERO should not have a 1:1 mapping, since PO (using the sub-pathing feature) allows hiding parts of the service plane to unauthorised requesters. One more issue, I find the sub-pathing capability specially interesting for security (authorisation) issue (who can/cannot request info about a service along a given NSA, etc.). @John, what does CTP (C* Transit Points) stand for? Most probably it comes from the call I missed, sorry about that! regards, -- Joan A. García-Espín CTX, i2CAT Foundation El 20/01/2010, a las 21:26, John Vollbrecht escribió: > This is very good - thank you very much. Some comments in line -- > except one here -- I like the name CTP rather than STP. A major > reason is that this is on the transport plane, not the service plane, > and calling it service termination seems to me to imply service > plane. I leave this discussion to later as it doesn't affect the meat > of the discussion. > > > On Jan 20, 2010, at 2:24 PM, Jerry Sobieski wrote: > >> Here are some thoughts on what a "Path Object" (PO) should contain >> and/or be able to do...please read thru and think about this and let >> me >> know your thoughts. >> >> Jerry >> >> >> >> - A Path Object is an ordered list of service transit points (STPs) >> through which a connection passes. >> >> - A Path Object must have at least two STPs: The ingress STP, and the >> egress STP. >> >> - A Path Object should allow a path to be described using "sub-paths" >> (i.e. other Path Objects) or pointers/tags that reference other Path >> Objects. > - are there existing examples of this or is it a proposal? >> >> - A Path Object is direction sensitive. I.e. The path is always >> interpreted as beginning at the first STP (the head of the list), and >> proceeding towards the last STP (the tail) in the list. There is no >> implication that a path object is reversable (or bidirectional). >> > does this have to do with pathfinding or is there something more to > it? > >> - A "fully specified" path identifies the complete set of STPs - in >> order - that a connection transits from ingress to egress. >> > are these STPs for all resources in the path that are controlled by > different NRMs >> - A "partially specified" path identifies a subset of STPs - in >> order - >> that the connection transits - but not necessarily every STP the >> connection transits. THis is a "loose hop" path >> >> - A partially specified path may contain STPs that are, individually, >> only partially specified. For example, a path may contain a STP >> indicating a specific switching element to be transitted, without >> specifying the specific port or VLAN id to be used. This could also >> be >> generalized to indicate something as general as an particular >> network to >> be transitted. Alternatively, the path element may specify a "label >> set", i.e. a set of labels or STPs that can are acceptable within the >> context of that STP. THis may be useful for conveying valid VLAN >> IDs or >> Wavelengths that may be available to path selection functions >> downstream >> or for end-to-end tagging information. >> >> Path objects can be used in several ways: First, would be to specify >> constraints on a *proposed* path - i.e. must transit this switch, but >> port selection has full freedom. Or must transit this previously >> defned >> path. The path objects need wild card masks to indicate these >> constraints. Second use is to define a connect "as built", i.e. >> after >> the cnnection is full specified and/or in service, a fully specified >> detailed Path Object would capture the entire detailed path - end-to- >> end >> but perhaps not fully exposed. >> > I agree with this, but perhaps defining what is "required" and what is > "allowed" , especially in situations where a connection is made from > multiple RMAs in different provider agents. > > >> BNF format: >> >> <Path_Object> := <Path_Object_Header> <Path_List> >> >> <Path_List> := <STP> ( <Path_Object> | <STP> ) + | >> <Path_Object>+ >> >> Path elements can be STPs or Path Objects. STPs represent topology >> locations, these will likely be something such as: >> <domain_identifier><pointID> or <dom><node><port><label><...>. >> These >> will likely be alphanumeric strings, possibly parsable, or they may >> be >> binary structures... Likewise with Path Objects - these will likely >> be >> something like <domain><objectID>. The key concept however is that >> the >> Path Object contains two types of elements: service termination >> points >> that refer to points in the topology, and a path object tag that >> refer >> to another strucutre outside the current path object. So each >> elemnt of >> the path list must have a type code to say what type of path element >> it >> is, and then a string to uniquely dentify that object within a local >> context, and a length that says how long the object tag is. >> > > So, for something like the chain model where segments A-B-C are > included. Typically provider A gets request, inludes ingress and > egress of A in the path and forwards the path in a request to B. I > think the ingress and egress of A need to be either dropped or marked > as "not part of the request to B". I think this might be done > explicitly or by implication, but would be good to define. > > John > > >> >> >> >> _______________________________________________ >> nsi-wg mailing list >> nsi-wg@ogf.org >> http://www.ogf.org/mailman/listinfo/nsi-wg > > _______________________________________________ > nsi-wg mailing list > nsi-wg@ogf.org > http://www.ogf.org/mailman/listinfo/nsi-wg
CTP is Connection Termination Point -- as opposed to STP or Service Termination Point -- :) On Jan 21, 2010, at 11:45 AM, Joan A. Garcia-Espin wrote: > Thanks Jerry, it's a thorough description! > > Nevertheless, the definition of STPs is not 100% clear to me, and I > understand John's concerns regarding this. > As you described, Jerry, STPs may be understood as "pointers" to the > service interface of the entities (NSA) that are in charge of the > path. In other words, the URL or Service ID of the NSAs, which in > any case belong to the service plane, rather to the transport plane. > I'm not against this, on the contrary, I agree to have STPs in the > PO definition. In this case, the PO shows also a list of service > entities along the path. > > At this point I wonder if the PO is the service plane equivalent of > the ERO on the data/transport plane. Obviously, PO and ERO should > not have a 1:1 mapping, since PO (using the sub-pathing feature) > allows hiding parts of the service plane to unauthorised requesters. > > One more issue, I find the sub-pathing capability specially > interesting for security (authorisation) issue (who can/cannot > request info about a service along a given NSA, etc.). > > @John, what does CTP (C* Transit Points) stand for? Most probably > it comes from the call I missed, sorry about that! > > regards, > -- > Joan A. García-Espín > CTX, i2CAT Foundation > > > > > > El 20/01/2010, a las 21:26, John Vollbrecht escribió: > >> This is very good - thank you very much. Some comments in line -- >> except one here -- I like the name CTP rather than STP. A major >> reason is that this is on the transport plane, not the service plane, >> and calling it service termination seems to me to imply service >> plane. I leave this discussion to later as it doesn't affect the >> meat >> of the discussion. >> >> >> On Jan 20, 2010, at 2:24 PM, Jerry Sobieski wrote: >> >>> Here are some thoughts on what a "Path Object" (PO) should contain >>> and/or be able to do...please read thru and think about this and let >>> me >>> know your thoughts. >>> >>> Jerry >>> >>> >>> >>> - A Path Object is an ordered list of service transit points (STPs) >>> through which a connection passes. >>> >>> - A Path Object must have at least two STPs: The ingress STP, and >>> the >>> egress STP. >>> >>> - A Path Object should allow a path to be described using "sub- >>> paths" >>> (i.e. other Path Objects) or pointers/tags that reference other >>> Path >>> Objects. >> - are there existing examples of this or is it a proposal? >>> >>> - A Path Object is direction sensitive. I.e. The path is always >>> interpreted as beginning at the first STP (the head of the list), >>> and >>> proceeding towards the last STP (the tail) in the list. There is >>> no >>> implication that a path object is reversable (or bidirectional). >>> >> does this have to do with pathfinding or is there something more to >> it? >> >>> - A "fully specified" path identifies the complete set of STPs - in >>> order - that a connection transits from ingress to egress. >>> >> are these STPs for all resources in the path that are controlled by >> different NRMs >>> - A "partially specified" path identifies a subset of STPs - in >>> order - >>> that the connection transits - but not necessarily every STP the >>> connection transits. THis is a "loose hop" path >>> >>> - A partially specified path may contain STPs that are, >>> individually, >>> only partially specified. For example, a path may contain a STP >>> indicating a specific switching element to be transitted, without >>> specifying the specific port or VLAN id to be used. This could also >>> be >>> generalized to indicate something as general as an particular >>> network to >>> be transitted. Alternatively, the path element may specify a >>> "label >>> set", i.e. a set of labels or STPs that can are acceptable within >>> the >>> context of that STP. THis may be useful for conveying valid VLAN >>> IDs or >>> Wavelengths that may be available to path selection functions >>> downstream >>> or for end-to-end tagging information. >>> >>> Path objects can be used in several ways: First, would be to specify >>> constraints on a *proposed* path - i.e. must transit this switch, >>> but >>> port selection has full freedom. Or must transit this previously >>> defned >>> path. The path objects need wild card masks to indicate these >>> constraints. Second use is to define a connect "as built", i.e. >>> after >>> the cnnection is full specified and/or in service, a fully specified >>> detailed Path Object would capture the entire detailed path - end- >>> to- >>> end >>> but perhaps not fully exposed. >>> >> I agree with this, but perhaps defining what is "required" and what >> is >> "allowed" , especially in situations where a connection is made from >> multiple RMAs in different provider agents. >> >> >>> BNF format: >>> >>> <Path_Object> := <Path_Object_Header> <Path_List> >>> >>> <Path_List> := <STP> ( <Path_Object> | <STP> ) + | >>> <Path_Object>+ >>> >>> Path elements can be STPs or Path Objects. STPs represent topology >>> locations, these will likely be something such as: >>> <domain_identifier><pointID> or <dom><node><port><label><...>. >>> These >>> will likely be alphanumeric strings, possibly parsable, or they >>> may be >>> binary structures... Likewise with Path Objects - these will likely >>> be >>> something like <domain><objectID>. The key concept however is that >>> the >>> Path Object contains two types of elements: service termination >>> points >>> that refer to points in the topology, and a path object tag that >>> refer >>> to another strucutre outside the current path object. So each >>> elemnt of >>> the path list must have a type code to say what type of path element >>> it >>> is, and then a string to uniquely dentify that object within a local >>> context, and a length that says how long the object tag is. >>> >> >> So, for something like the chain model where segments A-B-C are >> included. Typically provider A gets request, inludes ingress and >> egress of A in the path and forwards the path in a request to B. I >> think the ingress and egress of A need to be either dropped or marked >> as "not part of the request to B". I think this might be done >> explicitly or by implication, but would be good to define. >> >> John >> >> >>> >>> >>> >>> _______________________________________________ >>> nsi-wg mailing list >>> nsi-wg@ogf.org >>> http://www.ogf.org/mailman/listinfo/nsi-wg >> >> _______________________________________________ >> nsi-wg mailing list >> nsi-wg@ogf.org >> http://www.ogf.org/mailman/listinfo/nsi-wg >
Hi Joan- A few notes that may shed light on my thinking on this
topic...(or not:-)
Ultimately, the PO must allow an agent to link from the list of
tags/handles/URIs/addresses in the PO to a point in the topology. The
identifier in the PO must be one that makes sense to the agent
referncing the PO for some purpose. If we use a TE-Address in each
hop, then that string that specifies each address should be recognized
by the agents as a TE Address. If we use URIs, then the agents should
recognize them as URIs. In either case, there must be some mechanism
that takes that hop identifier and associates it with some component of
the topology. This mechanism may be a sequence of lookups - ala DNS,
or ala URI("A") maps to Node="Switch1": Port="port 12":VLAN=2036;
URI("B") maps to ..., or it could be a parsable substring in the
URI,..., etc. The URI tag is a service level construct, but it must
relate/link somehow to the topology to which it applies. The STP URI
naming convention and URI->Topo resolution process are service level
constructs, but the STP itself is a point in the topology where the
service terminates or transits.
Hope this helps explain my thinking...
Jerry
Joan A. Garcia-Espin wrote:
> Thanks Jerry, it's a thorough description!
>
> Nevertheless, the definition of STPs is not 100% clear to me, and I
> understand John's concerns regarding this.
> As you described, Jerry, STPs may be understood as "pointers" to the
> service interface of the entities (NSA) that are in charge of the
> path. In other words, the URL or Service ID of the NSAs, which in any
> case belong to the service plane, rather to the transport plane.
> I'm not against this, on the contrary, I agree to have STPs in the PO
> definition. In this case, the PO shows also a list of service entities
> along the path.
>
> At this point I wonder if the PO is the service plane equivalent of
> the ERO on the data/transport plane. Obviously, PO and ERO should not
> have a 1:1 mapping, since PO (using the sub-pathing feature) allows
> hiding parts of the service plane to unauthorised requesters.
>
> One more issue, I find the sub-pathing capability specially
> interesting for security (authorisation) issue (who can/cannot request
> info about a service along a given NSA, etc.).
>
> @John, what does CTP (C* Transit Points) stand for? Most probably it
> comes from the call I missed, sorry about that!
>
> regards,
> --
> Joan A. García-Espín
> CTX, i2CAT Foundation
>
>
>
>
>
> El 20/01/2010, a las 21:26, John Vollbrecht escribió:
>
>> This is very good - thank you very much. Some comments in line --
>> except one here -- I like the name CTP rather than STP. A major
>> reason is that this is on the transport plane, not the service plane,
>> and calling it service termination seems to me to imply service
>> plane. I leave this discussion to later as it doesn't affect the meat
>> of the discussion.
>>
>>
>> On Jan 20, 2010, at 2:24 PM, Jerry Sobieski wrote:
>>
>>> Here are some thoughts on what a "Path Object" (PO) should contain
>>> and/or be able to do...please read thru and think about this and let
>>> me
>>> know your thoughts.
>>>
>>> Jerry
>>>
>>>
>>>
>>> - A Path Object is an ordered list of service transit points (STPs)
>>> through which a connection passes.
>>>
>>> - A Path Object must have at least two STPs: The ingress STP, and the
>>> egress STP.
>>>
>>> - A Path Object should allow a path to be described using "sub-paths"
>>> (i.e. other Path Objects) or pointers/tags that reference other Path
>>> Objects.
>> - are there existing examples of this or is it a proposal?
>>>
>>> - A Path Object is direction sensitive. I.e. The path is always
>>> interpreted as beginning at the first STP (the head of the list), and
>>> proceeding towards the last STP (the tail) in the list. There is no
>>> implication that a path object is reversable (or bidirectional).
>>>
>> does this have to do with pathfinding or is there something more to it?
>>
>>> - A "fully specified" path identifies the complete set of STPs - in
>>> order - that a connection transits from ingress to egress.
>>>
>> are these STPs for all resources in the path that are controlled by
>> different NRMs
>>> - A "partially specified" path identifies a subset of STPs - in
>>> order -
>>> that the connection transits - but not necessarily every STP the
>>> connection transits. THis is a "loose hop" path
>>>
>>> - A partially specified path may contain STPs that are, individually,
>>> only partially specified. For example, a path may contain a STP
>>> indicating a specific switching element to be transitted, without
>>> specifying the specific port or VLAN id to be used. This could also
>>> be
>>> generalized to indicate something as general as an particular
>>> network to
>>> be transitted. Alternatively, the path element may specify a "label
>>> set", i.e. a set of labels or STPs that can are acceptable within the
>>> context of that STP. THis may be useful for conveying valid VLAN
>>> IDs or
>>> Wavelengths that may be available to path selection functions
>>> downstream
>>> or for end-to-end tagging information.
>>>
>>> Path objects can be used in several ways: First, would be to specify
>>> constraints on a *proposed* path - i.e. must transit this switch, but
>>> port selection has full freedom. Or must transit this previously
>>> defned
>>> path. The path objects need wild card masks to indicate these
>>> constraints. Second use is to define a connect "as built", i.e.
>>> after
>>> the cnnection is full specified and/or in service, a fully specified
>>> detailed Path Object would capture the entire detailed path - end-to-
>>> end
>>> but perhaps not fully exposed.
>>>
>> I agree with this, but perhaps defining what is "required" and what is
>> "allowed" , especially in situations where a connection is made from
>> multiple RMAs in different provider agents.
>>
>>
>>> BNF format:
>>>
>>> <Path_Object> := <Path_Object_Header> <Path_List>
>>>
>>> <Path_List> := <STP> ( <Path_Object> | <STP> ) + |
>>> <Path_Object>+
>>>
>>> Path elements can be STPs or Path Objects. STPs represent topology
>>> locations, these will likely be something such as:
>>> <domain_identifier><pointID> or <dom><node><port><label><...>. These
>>> will likely be alphanumeric strings, possibly parsable, or they may be
>>> binary structures... Likewise with Path Objects - these will likely
>>> be
>>> something like <domain><objectID>. The key concept however is that
>>> the
>>> Path Object contains two types of elements: service termination points
>>> that refer to points in the topology, and a path object tag that refer
>>> to another strucutre outside the current path object. So each
>>> elemnt of
>>> the path list must have a type code to say what type of path element
>>> it
>>> is, and then a string to uniquely dentify that object within a local
>>> context, and a length that says how long the object tag is.
>>>
>>
>> So, for something like the chain model where segments A-B-C are
>> included. Typically provider A gets request, inludes ingress and
>> egress of A in the path and forwards the path in a request to B. I
>> think the ingress and egress of A need to be either dropped or marked
>> as "not part of the request to B". I think this might be done
>> explicitly or by implication, but would be good to define.
>>
>> John
>>
>>
>>>
>>>
>>>
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg@ogf.org
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg@ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>
Crystal clear :)
Agreed.
Regards,
--
Joan A. García-Espín
CTX, i2CAT Foundation
El 25/01/2010, a las 15:14, Jerry Sobieski escribió:
> Hi Joan- A few notes that may shed light on my thinking on this
> topic...(or not:-)
>
> Ultimately, the PO must allow an agent to link from the list of tags/
> handles/URIs/addresses in the PO to a point in the topology. The
> identifier in the PO must be one that makes sense to the agent
> referncing the PO for some purpose. If we use a TE-Address in each
> hop, then that string that specifies each address should be
> recognized by the agents as a TE Address. If we use URIs, then the
> agents should recognize them as URIs. In either case, there must
> be some mechanism that takes that hop identifier and associates it
> with some component of the topology. This mechanism may be a
> sequence of lookups - ala DNS, or ala URI("A") maps to
> Node="Switch1": Port="port 12":VLAN=2036; URI("B") maps to ..., or
> it could be a parsable substring in the URI,..., etc. The URI
> tag is a service level construct, but it must relate/link somehow to
> the topology to which it applies. The STP URI naming convention
> and URI->Topo resolution process are service level constructs, but
> the STP itself is a point in the topology where the service
> terminates or transits.
>
> Hope this helps explain my thinking...
> Jerry
>
>
>
> Joan A. Garcia-Espin wrote:
>> Thanks Jerry, it's a thorough description!
>>
>> Nevertheless, the definition of STPs is not 100% clear to me, and I
>> understand John's concerns regarding this.
>> As you described, Jerry, STPs may be understood as "pointers" to
>> the service interface of the entities (NSA) that are in charge of
>> the path. In other words, the URL or Service ID of the NSAs, which
>> in any case belong to the service plane, rather to the transport
>> plane.
>> I'm not against this, on the contrary, I agree to have STPs in the
>> PO definition. In this case, the PO shows also a list of service
>> entities along the path.
>>
>> At this point I wonder if the PO is the service plane equivalent of
>> the ERO on the data/transport plane. Obviously, PO and ERO should
>> not have a 1:1 mapping, since PO (using the sub-pathing feature)
>> allows hiding parts of the service plane to unauthorised requesters.
>>
>> One more issue, I find the sub-pathing capability specially
>> interesting for security (authorisation) issue (who can/cannot
>> request info about a service along a given NSA, etc.).
>>
>> @John, what does CTP (C* Transit Points) stand for? Most probably
>> it comes from the call I missed, sorry about that!
>>
>> regards,
>> --
>> Joan A. García-Espín
>> CTX, i2CAT Foundation
>>
>>
>>
>>
>>
>> El 20/01/2010, a las 21:26, John Vollbrecht escribió:
>>
>>> This is very good - thank you very much. Some comments in line --
>>> except one here -- I like the name CTP rather than STP. A major
>>> reason is that this is on the transport plane, not the service
>>> plane,
>>> and calling it service termination seems to me to imply service
>>> plane. I leave this discussion to later as it doesn't affect the
>>> meat
>>> of the discussion.
>>>
>>>
>>> On Jan 20, 2010, at 2:24 PM, Jerry Sobieski wrote:
>>>
>>>> Here are some thoughts on what a "Path Object" (PO) should contain
>>>> and/or be able to do...please read thru and think about this and
>>>> let
>>>> me
>>>> know your thoughts.
>>>>
>>>> Jerry
>>>>
>>>>
>>>>
>>>> - A Path Object is an ordered list of service transit points (STPs)
>>>> through which a connection passes.
>>>>
>>>> - A Path Object must have at least two STPs: The ingress STP, and
>>>> the
>>>> egress STP.
>>>>
>>>> - A Path Object should allow a path to be described using "sub-
>>>> paths"
>>>> (i.e. other Path Objects) or pointers/tags that reference other
>>>> Path
>>>> Objects.
>>> - are there existing examples of this or is it a proposal?
>>>>
>>>> - A Path Object is direction sensitive. I.e. The path is always
>>>> interpreted as beginning at the first STP (the head of the list),
>>>> and
>>>> proceeding towards the last STP (the tail) in the list. There
>>>> is no
>>>> implication that a path object is reversable (or bidirectional).
>>>>
>>> does this have to do with pathfinding or is there something more
>>> to it?
>>>
>>>> - A "fully specified" path identifies the complete set of STPs -
>>>> in
>>>> order - that a connection transits from ingress to egress.
>>>>
>>> are these STPs for all resources in the path that are controlled by
>>> different NRMs
>>>> - A "partially specified" path identifies a subset of STPs - in
>>>> order -
>>>> that the connection transits - but not necessarily every STP the
>>>> connection transits. THis is a "loose hop" path
>>>>
>>>> - A partially specified path may contain STPs that are,
>>>> individually,
>>>> only partially specified. For example, a path may contain a STP
>>>> indicating a specific switching element to be transitted, without
>>>> specifying the specific port or VLAN id to be used. This could
>>>> also
>>>> be
>>>> generalized to indicate something as general as an particular
>>>> network to
>>>> be transitted. Alternatively, the path element may specify a
>>>> "label
>>>> set", i.e. a set of labels or STPs that can are acceptable within
>>>> the
>>>> context of that STP. THis may be useful for conveying valid VLAN
>>>> IDs or
>>>> Wavelengths that may be available to path selection functions
>>>> downstream
>>>> or for end-to-end tagging information.
>>>>
>>>> Path objects can be used in several ways: First, would be to
>>>> specify
>>>> constraints on a *proposed* path - i.e. must transit this switch,
>>>> but
>>>> port selection has full freedom. Or must transit this previously
>>>> defned
>>>> path. The path objects need wild card masks to indicate these
>>>> constraints. Second use is to define a connect "as built", i.e.
>>>> after
>>>> the cnnection is full specified and/or in service, a fully
>>>> specified
>>>> detailed Path Object would capture the entire detailed path - end-
>>>> to-
>>>> end
>>>> but perhaps not fully exposed.
>>>>
>>> I agree with this, but perhaps defining what is "required" and
>>> what is
>>> "allowed" , especially in situations where a connection is made from
>>> multiple RMAs in different provider agents.
>>>
>>>
>>>> BNF format:
>>>>
>>>> <Path_Object> := <Path_Object_Header> <Path_List>
>>>>
>>>> <Path_List> := <STP> ( <Path_Object> | <STP> ) + |
>>>> <Path_Object>+
>>>>
>>>> Path elements can be STPs or Path Objects. STPs represent topology
>>>> locations, these will likely be something such as:
>>>> <domain_identifier><pointID> or <dom><node><port><label><...>.
>>>> These
>>>> will likely be alphanumeric strings, possibly parsable, or they
>>>> may be
>>>> binary structures... Likewise with Path Objects - these will
>>>> likely
>>>> be
>>>> something like <domain><objectID>. The key concept however is
>>>> that
>>>> the
>>>> Path Object contains two types of elements: service termination
>>>> points
>>>> that refer to points in the topology, and a path object tag that
>>>> refer
>>>> to another strucutre outside the current path object. So each
>>>> elemnt of
>>>> the path list must have a type code to say what type of path
>>>> element
>>>> it
>>>> is, and then a string to uniquely dentify that object within a
>>>> local
>>>> context, and a length that says how long the object tag is.
>>>>
>>>
>>> So, for something like the chain model where segments A-B-C are
>>> included. Typically provider A gets request, inludes ingress and
>>> egress of A in the path and forwards the path in a request to B. I
>>> think the ingress and egress of A need to be either dropped or
>>> marked
>>> as "not part of the request to B". I think this might be done
>>> explicitly or by implication, but would be good to define.
>>>
>>> John
>>>
>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> nsi-wg mailing list
>>>> nsi-wg@ogf.org
>>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>>
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg@ogf.org
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>
See comments in line... John Vollbrecht wrote: > This is very good - thank you very much. Some comments in line -- > except one here -- I like the name CTP rather than STP. A major > reason is that this is on the transport plane, not the service plane, > and calling it service termination seems to me to imply service > plane. I leave this discussion to later as it doesn't affect the meat > of the discussion. > My reasoning is that the "service" terminates at certain points in the topology - whether or not a connection is active. The service can be delivered to those points. While these are point in the tranport plane, they represent those locations at the edge of a contiguous service domain. Once a service instance is established, i.e. a circuit or connection, then the end points of that connection could be called "connection Termination points". But I do not think CTP is adequate when refering to the set of points that are reachable by the overall service. BTW & FYI- GN3 is using the term Service Demarcation Point "SDP" in the inter-domain service architecture document. > > On Jan 20, 2010, at 2:24 PM, Jerry Sobieski wrote: > >> Here are some thoughts on what a "Path Object" (PO) should contain >> and/or be able to do...please read thru and think about this and let me >> know your thoughts. >> >> Jerry >> >> >> >> - A Path Object is an ordered list of service transit points (STPs) >> through which a connection passes. >> >> - A Path Object must have at least two STPs: The ingress STP, and the >> egress STP. >> >> - A Path Object should allow a path to be described using "sub-paths" >> (i.e. other Path Objects) or pointers/tags that reference other Path >> Objects. > - are there existing examples of this or is it a proposal? This is a proposal - AFAIK it is new idea to support a means of describing a Path as containing one or more "path segments" which are implied to be concatenated (although the concept is found in many other areas of tree structures and linked lists) This notion requires that the Path Object have a handle that can be resolved to find a structure or database record(s) that describe the subpath in terms [ultimately] of STPs. If you look at the form of the Path Object I proposed, it should ultimately resolve into a list of STPs once all the sub-paths are expanded. And further, a PO must contain at a minimum two STPs - the ingress and egress STPs. >> >> - A Path Object is direction sensitive. I.e. The path is always >> interpreted as beginning at the first STP (the head of the list), and >> proceeding towards the last STP (the tail) in the list. There is no >> implication that a path object is reversable (or bidirectional). >> > does this have to do with pathfinding or is there something more to it? Hmmm... a path object refers to a sequence of points in a topology. There is nothing in the path object itself that states the purpose or context within which the path object was built or can/should be used. Therefore, we can not assume that the notion of proceeding from point A to point Z is equivalent if posed as proceeding from Z to A. Indeed, the reverse path might be useful in some context, but we cannot assume that always (or ever) to be the case. Reversability is a function of the context in which the PO is used. > >> - A "fully specified" path identifies the complete set of STPs - in >> order - that a connection transits from ingress to egress. >> > are these STPs for all resources in the path that are controlled by > different NRMs IN theory, a fuly specified Path Object would enumerate every valid service transit/termination point that the path traverses. In practice, this will likely never be attainable since much of the path detail is local within each domain and in some cases may not be relevant (take the case of the reseller connection being reallocated - is this resold connection a concatenated part of the user connection? or is it a tunnel thru which the user sees simply the two end STPs?) So it may not be terribly important to define a "fully" specified path object as it may not be something one can discern by looking at it, or will likely ever actually see in the wild. But the notion of "pinned" paths - i.e. loose hop paths or partially specified paths - is important. >> - A "partially specified" path identifies a subset of STPs - in order - >> that the connection transits - but not necessarily every STP the >> connection transits. THis is a "loose hop" path >> >> - A partially specified path may contain STPs that are, individually, >> only partially specified. For example, a path may contain a STP >> indicating a specific switching element to be transitted, without >> specifying the specific port or VLAN id to be used. This could also be >> generalized to indicate something as general as an particular network to >> be transitted. Alternatively, the path element may specify a "label >> set", i.e. a set of labels or STPs that can are acceptable within the >> context of that STP. THis may be useful for conveying valid VLAN IDs or >> Wavelengths that may be available to path selection functions downstream >> or for end-to-end tagging information. >> >> Path objects can be used in several ways: First, would be to specify >> constraints on a *proposed* path - i.e. must transit this switch, but >> port selection has full freedom. Or must transit this previously defned >> path. The path objects need wild card masks to indicate these >> constraints. Second use is to define a connect "as built", i.e. after >> the cnnection is full specified and/or in service, a fully specified >> detailed Path Object would capture the entire detailed path - end-to-end >> but perhaps not fully exposed. >> > I agree with this, but perhaps defining what is "required" and what is > "allowed" , especially in situations where a connection is made from > multiple RMAs in different provider agents. In terms of NSI, and in particular the NSI "Connection Service", I think we need to discuss and define what an NRM will expect and return. We interact with an NRM to reserve resources we know that NRM is responsible for - which means we have some topology information that tells us this. So if our path finding suggests we'd like to at least try to allocate those resources, we can only specify them to the extent they exist in our topology DB. If as we stipulated yesterday that the NRM uses an NSI protocol to communicate with a higher tier NSA, then we use the same NSI notions of STP and to describe the Path once it is confirmed. It is the NRMs responsibility to do any hardware specific munging necessary to return an NSI compliant Path confirmation. > > >> BNF format: >> >> <Path_Object> := <Path_Object_Header> <Path_List> >> >> <Path_List> := <STP> ( <Path_Object> | <STP> ) + | <Path_Object>+ >> >> Path elements can be STPs or Path Objects. STPs represent topology >> locations, these will likely be something such as: >> <domain_identifier><pointID> or <dom><node><port><label><...>. These >> will likely be alphanumeric strings, possibly parsable, or they may be >> binary structures... Likewise with Path Objects - these will likely be >> something like <domain><objectID>. The key concept however is that the >> Path Object contains two types of elements: service termination points >> that refer to points in the topology, and a path object tag that refer >> to another strucutre outside the current path object. So each elemnt of >> the path list must have a type code to say what type of path element it >> is, and then a string to uniquely dentify that object within a local >> context, and a length that says how long the object tag is. >> > > So, for something like the chain model where segments A-B-C are > included. Typically provider A gets request, inludes ingress and > egress of A in the path and forwards the path in a request to B. I > think the ingress and egress of A need to be either dropped or marked > as "not part of the request to B". I think this might be done > explicitly or by implication, but would be good to define. > In the Chain Model, the path is nominated and explored forward, but confirmed backward. The Path Object is actually built backwards as the local [confirmed] portion of the path is prepended to the confirmed downstream portion of the path, and the resulting path object confirmed and returned upstream towards the originating requester. The Path Object structure itself may be manipulated in lots of ways - it may be built forward or backward or from the center as requests or confrmations are sent/received, it may be editted and/or expanded or reduced based on lots of different needs or processes. And I can see there would be intermediate or temporary path objects that might be necessary during path finding/reserving process, or for other related processes. How it is constructed will be a function of the process that constructs it, but thats perfectly fine. Ultimately, a valid Path Object should provide information describing a tour through a topology. I suggest this should be an ordered sequence of points that the tour must/does transit. And it must minimally have a starting point and and ending point. For NSI purposes, I suggest that the PO should consist of two basic path elements: 1) an actual transit point, and 2) an element that refers to another [sub] path object. Note: while the path object must provide path information, this does not mean that all path information in a path object must be exposed to all agents. We could say the path object should be able to provide the technical path information to a duly authorized agent. So the subpath object would be an implicit means of forcing an agent to obtain authorization in order to access the technical path data in that PO. Technically, I think the subpath may also be useful for things like protection and SRLG handling, etc. Further, We should differentiate a "Connection Object" from a "Path Object". The former will likely contain one or more of the latter. I.e. A Connection may be comprised of both a forward Path Object, and a backward Path Object. It is important to keep the characteristics of a circuit or a Connection separate from the object that specifies the path. Another complexity we may need to address n the future is point-to-multipoint Connections and how we describe those circuits and the paths that make them up. Hope all this sounds lucid:-) Jerry
On 20/01/2010 20:24, Jerry Sobieski wrote:
- A "partially specified" path identifies a subset of STPs - in order - that the connection transits - but not necessarily every STP the connection transits. THis is a "loose hop" path
Do you propose to make this implicit or explicit? That is, is there a "loose hop" object/marker in the STP? I would think that some kind of marker is required in order to make this work, and clear to the other parties that part of the STP is hidden. The loose hop object could also be used to specify whether the "loose" resources have been provisioned, or not, and to specify other kinds of information about the possible path there. Jeroen.
Hi Jeroen- Hmm... I had always assumed that this would be implicit - that a strict hop PO and Loose hop PO would not really look any different.... But honestly I had not considered whther this was necessary or not. My thought was that whatever agent was using the Path Object would need to check it against the topology anyway - in essence perform a Path Computation between Hop(n) and Hop(n+1). If they are adjacent, this would be an almost zero cost check, and if they were not adjacent, a Path Comp would be needed anyway. I don't know that being explicit relieves any agent from checking adjacency, but there may be some error conditions that are detected if the expectation is explicit in some way. There may be a need to indicate when a hop was/is expected to be adjacent (e.g. a strict hop "as-built" PO that describes a provisioned path after the fact vs a reserved PO that may or may not be strict) This also brings up the issue of whether the underlying topology can change between when a Path Object is created and when that Path Object is referenced/used. I.e. What happens if a specified hop no longer exists? Or if additional switching points are introduced between say when a reservation is created, and when the connection is provisioned? I don't think I have a position on the question to making strict vs loose explicit - it might be useful or necessary. Or it may be superfluous. Would we specify each particular hop as strict or loose? Or simply indicate the entire PO as strict or loose? (I'd say hop by hop would be best). Perhaps we allow for a boolean indicator on each hop that says this is "strict hop" to previous hop. If it is not set it could be eiterh loose or strict, but if it *is* set, then the hop must be strict. Also, as we discuss this, we must formulate what we mean by "adjacent". IMO, adjacent means adjacent in terms of provisioning - i.e. nominally, a switching point that must be re-configured as part of provisioning is a hop that should be presnt in a strict hop PO. If a switching point exists only as part of an underlying tunnel connection, and it is not seen as part of the Path Finding process and not reconfigured as part of a connection's provisioning process, then it is not part of the PO. For example, a Ethernet link established between Cern and Argonne would be seen as a single link in the topology when allocating Layer2 connections. While there may be lots of switching points that went into setting up that express Etehrnet connection, as far as the Path Finder is concerend, there is one ethernet STP in Cern and one in Argonne, and so provisioning a path between Cern and US over that link would not indicate all those lower layer switching SDH and Wave and Fiber switching points. None of them were reconfigured as part of a connectionusing that long link. However, if a connection is built that adapts the PDU from an Ethernet VLAN into a GFP payload on a sonet link, then that adaptation point is something that is visible to the Path Finder in the topology and is something that is reconfigured to establsih the connection - the Ethernet egress and the GFP ingress STPs are specifically part of the circuit and should be in a strict hop PO. To be complete, that long express Ethernet link would have a strict PO, but it would be associated with that a connection request from another agent somewhere, not with any particular connection riding over the top of it at the time. THis is probably clear as mud, (:-) but I hope this is useful. Jerry Jeroen van der Ham wrote:
On 20/01/2010 20:24, Jerry Sobieski wrote:
- A "partially specified" path identifies a subset of STPs - in order - that the connection transits - but not necessarily every STP the connection transits. THis is a "loose hop" path
Do you propose to make this implicit or explicit? That is, is there a "loose hop" object/marker in the STP?
I would think that some kind of marker is required in order to make this work, and clear to the other parties that part of the STP is hidden.
The loose hop object could also be used to specify whether the "loose" resources have been provisioned, or not, and to specify other kinds of information about the possible path there.
Jeroen. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hi Jerry - Thanks for doing this -- I am guessing it will generate a lot of discussion, but that is good. I have a number of questions and comments on thinking about this. 1) I would think that there is a difference in loose hop and strict hop if loose hop is optional and strict hop is not. 2) I am wondering if strict hop for NSI purposes includes ingress and egress from resources controlled by NRM. NRM is the atomic controller for the resource. 3) For some requests the NRM may not want to be advertised/ known by all other NRMs. Is that possible? 4) I would think that a path might be "tentative" vs configured - tentative being a request and possibly including some options and configured being what is reserved/ granted to the requestor. I am also thinking that what is configured might be used directly by GMPLS implementations if GMPLS is supported on all resources. It might also be used in NSI provisioning requests. I wonder if it would look different in those different cases. 5) Does a path object include a pointer to the agent that could or has authorized it? This seems a crucial question and determines if that info must be provided outside the path via some sort of db. I realize that if it is included it might also have such a db, but it could be searched once, especially in the chain-like implementations of provider agents. -- John On Jan 25, 2010, at 8:51 AM, Jerry Sobieski wrote:
Hi Jeroen-
Hmm... I had always assumed that this would be implicit - that a strict hop PO and Loose hop PO would not really look any different.... But honestly I had not considered whther this was necessary or not. My thought was that whatever agent was using the Path Object would need to check it against the topology anyway - in essence perform a Path Computation between Hop(n) and Hop(n+1). If they are adjacent, this would be an almost zero cost check, and if they were not adjacent, a Path Comp would be needed anyway. I don't know that being explicit relieves any agent from checking adjacency, but there may be some error conditions that are detected if the expectation is explicit in some way. There may be a need to indicate when a hop was/is expected to be adjacent (e.g. a strict hop "as-built" PO that describes a provisioned path after the fact vs a reserved PO that may or may not be strict)
This also brings up the issue of whether the underlying topology can change between when a Path Object is created and when that Path Object is referenced/used. I.e. What happens if a specified hop no longer exists? Or if additional switching points are introduced between say when a reservation is created, and when the connection is provisioned?
I don't think I have a position on the question to making strict vs loose explicit - it might be useful or necessary. Or it may be superfluous. Would we specify each particular hop as strict or loose? Or simply indicate the entire PO as strict or loose? (I'd say hop by hop would be best). Perhaps we allow for a boolean indicator on each hop that says this is "strict hop" to previous hop. If it is not set it could be eiterh loose or strict, but if it *is* set, then the hop must be strict.
Also, as we discuss this, we must formulate what we mean by "adjacent". IMO, adjacent means adjacent in terms of provisioning - i.e. nominally, a switching point that must be re-configured as part of provisioning is a hop that should be presnt in a strict hop PO. If a switching point exists only as part of an underlying tunnel connection, and it is not seen as part of the Path Finding process and not reconfigured as part of a connection's provisioning process, then it is not part of the PO.
For example, a Ethernet link established between Cern and Argonne would be seen as a single link in the topology when allocating Layer2 connections. While there may be lots of switching points that went into setting up that express Etehrnet connection, as far as the Path Finder is concerend, there is one ethernet STP in Cern and one in Argonne, and so provisioning a path between Cern and US over that link would not indicate all those lower layer switching SDH and Wave and Fiber switching points. None of them were reconfigured as part of a connectionusing that long link. However, if a connection is built that adapts the PDU from an Ethernet VLAN into a GFP payload on a sonet link, then that adaptation point is something that is visible to the Path Finder in the topology and is something that is reconfigured to establsih the connection - the Ethernet egress and the GFP ingress STPs are specifically part of the circuit and should be in a strict hop PO. To be complete, that long express Ethernet link would have a strict PO, but it would be associated with that a connection request from another agent somewhere, not with any particular connection riding over the top of it at the time.
THis is probably clear as mud, (:-) but I hope this is useful.
Jerry
Jeroen van der Ham wrote:
On 20/01/2010 20:24, Jerry Sobieski wrote:
- A "partially specified" path identifies a subset of STPs - in order - that the connection transits - but not necessarily every STP the connection transits. THis is a "loose hop" path
Do you propose to make this implicit or explicit? That is, is there a "loose hop" object/marker in the STP?
I would think that some kind of marker is required in order to make this work, and clear to the other parties that part of the STP is hidden.
The loose hop object could also be used to specify whether the "loose" resources have been provisioned, or not, and to specify other kinds of information about the possible path there.
Jeroen. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hi Jerry -
Thanks for doing this -- I am guessing it will generate a lot of discussion, but that is good. I have a number of questions and comments on thinking about this.
1) I would think that there is a difference in loose hop and strict hop if loose hop is optional and strict hop is not. Not sure what you mean here... From Jeroen's comments, we might have two indicator bits: one that says "This hop is strict", and a second
2) I am wondering if strict hop for NSI purposes includes ingress and egress from resources controlled by NRM. NRM is the atomic controller for the resource. Even an opaque topology must still have edge points that interface with
3) For some requests the NRM may not want to be advertised/ known by all other NRMs. Is that possible? I do not think the Path Object should reference the NRM or NSAs at all. The PO references *only* points in the topology to describe a
4) I would think that a path might be "tentative" vs configured - tentative being a request and possibly including some options and configured being what is reserved/ granted to the requestor. I am also thinking that what is configured might be used directly by GMPLS implementations if GMPLS is supported on all resources. It might also be used in NSI provisioning requests. I wonder if it would look different in those different cases. Here is an example of the different purposes I was referring to. If you have an agent (say some middleware agent) that wants to denote some
Some thoughts/comments in line... John Vollbrecht wrote: that says "This hop is required". The former means that this hop should be and is expected to be adjacent to the previous hop within the service transport layer. The latter would mean that if this hop is not available, at some point when the PO is referenced, then an error condition should be raised (the alternative is to ignore the hop). I don't think we need the "required" bit - if the hop is in the PO, it is implied to be required (IMO). The "strict" bit probably would be useful, but we should discuss what it means for a hop that is actually a reference toa subpath object. the rest of the universe. Those edge egress STPs must be linked to specific ingress STPs on the other side of the link so that connections can be progressed across specific interdomain links. So, a remote domain would reveal its edge STPs that serve me, but maybe not others. I may never see and edge STP on the far side of a transit domain. Whether a domain reveals the ingress and egress STPs in a PO is up to the domain. If it does not, there may be difficulties for interactions with domains further downstream, but it should not affect most things (I think). path - nothing more. I am pretty adamant about this because the PO will likely be used for a number of differnet purposes - we don't want it to duplicate information for every possible purpose - information that is best maintained elsewhere...and I think the mapping between an STP and the NSA/NRM is best maintained someplace more authoritative. However (:-), it *is* necessary that there be an explicit means within the NSI architecture for STP identifiers (service locations) to be mapped to domains in which they reside, relevant NSAs and/or NRMs, policy, etc. But since this will be done for lots of different reasons, I think it should be an explicitly defined aspect of the architecture and an explicit separate service from the NSI Connection Service. I personally like the notion of a URI style name for STPs and POs. An named object should be of the form //<domain>/<subdomain>... /<name>, ala "//Allen/A" where A is the endpoint name, and everything in front is a domain identifier. This makes the domain obvious and explicit for an STP or PO or other object. There are some still soe open issues on this, but we do need this fundamental mapping from <endpoint name> to <location in global topology> that has to happen somehow.... Also, I think the population and maintanence of the name resolution service must be distributed and automated. path as tentative, then that is a function of that agent and we don't care how you implement tht functionality inside your agent. But if the NSI architecture needs to exchange path information between agents, then we need a standard NSI Path Object. Again the purpose of the PO is to describe a *path* not to describe the status or purpose of the path. In your example above, I think you overlay Path Object with Connection Object ...they are not te same. I do see paths being specified in differing degrees of detail. For example, a user may specify a loose PO that has three hops: ingress, intermediate STP, and the egress. However, by the time the connection is provisioned that PO may be substantially larger and more complex as there are now dozens of STPs - some in opaque POs - that go into the "as-built" PO. Here again, whether the PO is strict or loose or a mix does not really affect how we describe the path itself. In this example, the "connection object" may indicate a lot more information about the resources along the path than the PO itself carries. I think our PO is close to the ERO of GMPLS - but things like hops pointing to other path objects takes it a bit further. I don't think we should assume or favor any intradomain protocol or architecture. I suggest we focus on what NSI needs to function as a complete architecture, and let specific code implementations handle any protovcol conversion necessary.
5) Does a path object include a pointer to the agent that could or has authorized it? This seems a crucial question and determines if that info must be provided outside the path via some sort of db. I realize that if it is included it might also have such a db, but it could be searched once, especially in the chain-like implementations of provider agents.
Why would this be crucial to be in the PO? I think you are trying to make the Path Object into a Connection Object which would almost certainly contain considerably more information. A conncetion is typically bidirectional, carries all types of *connection related* parameters including authorization credntials, probably monitoring hooks/pointers, etc. The "Path Object" is just the path. Maybe we should discuss what a "connection object" should be ?...
-- John
On Jan 25, 2010, at 8:51 AM, Jerry Sobieski wrote:
Hi Jeroen-
Hmm... I had always assumed that this would be implicit - that a strict hop PO and Loose hop PO would not really look any different.... But honestly I had not considered whther this was necessary or not. My thought was that whatever agent was using the Path Object would need to check it against the topology anyway - in essence perform a Path Computation between Hop(n) and Hop(n+1). If they are adjacent, this would be an almost zero cost check, and if they were not adjacent, a Path Comp would be needed anyway. I don't know that being explicit relieves any agent from checking adjacency, but there may be some error conditions that are detected if the expectation is explicit in some way. There may be a need to indicate when a hop was/is expected to be adjacent (e.g. a strict hop "as-built" PO that describes a provisioned path after the fact vs a reserved PO that may or may not be strict)
This also brings up the issue of whether the underlying topology can change between when a Path Object is created and when that Path Object is referenced/used. I.e. What happens if a specified hop no longer exists? Or if additional switching points are introduced between say when a reservation is created, and when the connection is provisioned?
I don't think I have a position on the question to making strict vs loose explicit - it might be useful or necessary. Or it may be superfluous. Would we specify each particular hop as strict or loose? Or simply indicate the entire PO as strict or loose? (I'd say hop by hop would be best). Perhaps we allow for a boolean indicator on each hop that says this is "strict hop" to previous hop. If it is not set it could be eiterh loose or strict, but if it *is* set, then the hop must be strict.
Also, as we discuss this, we must formulate what we mean by "adjacent". IMO, adjacent means adjacent in terms of provisioning - i.e. nominally, a switching point that must be re-configured as part of provisioning is a hop that should be presnt in a strict hop PO. If a switching point exists only as part of an underlying tunnel connection, and it is not seen as part of the Path Finding process and not reconfigured as part of a connection's provisioning process, then it is not part of the PO.
For example, a Ethernet link established between Cern and Argonne would be seen as a single link in the topology when allocating Layer2 connections. While there may be lots of switching points that went into setting up that express Etehrnet connection, as far as the Path Finder is concerend, there is one ethernet STP in Cern and one in Argonne, and so provisioning a path between Cern and US over that link would not indicate all those lower layer switching SDH and Wave and Fiber switching points. None of them were reconfigured as part of a connectionusing that long link. However, if a connection is built that adapts the PDU from an Ethernet VLAN into a GFP payload on a sonet link, then that adaptation point is something that is visible to the Path Finder in the topology and is something that is reconfigured to establsih the connection - the Ethernet egress and the GFP ingress STPs are specifically part of the circuit and should be in a strict hop PO. To be complete, that long express Ethernet link would have a strict PO, but it would be associated with that a connection request from another agent somewhere, not with any particular connection riding over the top of it at the time.
THis is probably clear as mud, (:-) but I hope this is useful.
Jerry
Jeroen van der Ham wrote:
On 20/01/2010 20:24, Jerry Sobieski wrote:
- A "partially specified" path identifies a subset of STPs - in order - that the connection transits - but not necessarily every STP the connection transits. THis is a "loose hop" path
Do you propose to make this implicit or explicit? That is, is there a "loose hop" object/marker in the STP?
I would think that some kind of marker is required in order to make this work, and clear to the other parties that part of the STP is hidden.
The loose hop object could also be used to specify whether the "loose" resources have been provisioned, or not, and to specify other kinds of information about the possible path there.
Jeroen. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
Jerry - thanks again -- good discussion - we might continue tomorrow on call. comments in line below -- On Jan 26, 2010, at 1:16 PM, Jerry Sobieski wrote:
Some thoughts/comments in line...
John Vollbrecht wrote:
Hi Jerry -
Thanks for doing this -- I am guessing it will generate a lot of discussion, but that is good. I have a number of questions and comments on thinking about this.
1) I would think that there is a difference in loose hop and strict hop if loose hop is optional and strict hop is not.
Not sure what you mean here... From Jeroen's comments, we might have two indicator bits: one that says "This hop is strict", and a second that says "This hop is required". The former means that this hop should be and is expected to be adjacent to the previous hop within the service transport layer.
So adjacent needs to be defined. Do you mean ordered, in the sense that other hops might be inserted but the order must be correct? This might be the case where a high level set of POs might be requested and these might later include lower (hierarchically) paths. Or is there a definition of adjacent that requires lowest level POs (and what is lowest)?
The latter would mean that if this hop is not available, at some point when the PO is referenced, then an error condition should be raised (the alternative is to ignore the hop). I don't think we need the "required" bit - if the hop is in the PO, it is implied to be required (IMO). The "strict" bit probably would be useful, but we should discuss what it means for a hop that is actually a reference toa subpath object. Required might be similar to the first definition above.
2) I am wondering if strict hop for NSI purposes includes ingress and egress from resources controlled by NRM. NRM is the atomic controller for the resource. Even an opaque topology must still have edge points that interface with the rest of the universe. Those edge egress STPs must be linked to specific ingress STPs on the other side of the link so that connections can be progressed across specific interdomain links. So, a remote domain would reveal its edge STPs that serve me, but maybe not others. I may never see and edge STP on the far side of a transit domain. Whether a domain reveals the ingress and egress STPs in a PO is up to the domain. If it does not, there may be difficulties for interactions with domains further downstream, but it should not affect most things (I think).
Actually this raises a point I am worrying about -- does a STP exist on both connections that are concatenated, or is a STP the place where they are concatenated? I also wonder about how this plays with instantiation and monitoring of a connection on a path. Presumably path is required for these as well as request.
3) For some requests the NRM may not want to be advertised/ known by all other NRMs. Is that possible? I do not think the Path Object should reference the NRM or NSAs at all. The PO references *only* points in the topology to describe a path - nothing more. I am pretty adamant about this because the PO will likely be used for a number of differnet purposes - we don't want it to duplicate information for every possible purpose - information that is best maintained elsewhere...and I think the mapping between an STP and the NSA/NRM is best maintained someplace more authoritative.
any ideas of where? I think this is an ok answer, but would like to have an alternative if its not there.
However (:-), it *is* necessary that there be an explicit means within the NSI architecture for STP identifiers (service locations) to be mapped to domains in which they reside, relevant NSAs and/or NRMs, policy, etc. But since this will be done for lots of different reasons, I think it should be an explicitly defined aspect of the architecture and an explicit separate service from the NSI Connection Service.
ok - as noted above
I personally like the notion of a URI style name for STPs and POs. An named object should be of the form //<domain>/<subdomain>... / <name>, ala "//Allen/A" where A is the endpoint name, and everything in front is a domain identifier. This makes the domain obvious and explicit for an STP or PO or other object. There are some still soe open issues on this, but we do need this fundamental mapping from <endpoint name> to <location in global topology> that has to happen somehow.... Also, I think the population and maintanence of the name resolution service must be distributed and automated.
at least defined. I happen to think that for some deployments it might be fairly small and static and could be just a table in an agent.
4) I would think that a path might be "tentative" vs configured - tentative being a request and possibly including some options and configured being what is reserved/ granted to the requestor. I am also thinking that what is configured might be used directly by GMPLS implementations if GMPLS is supported on all resources. It might also be used in NSI provisioning requests. I wonder if it would look different in those different cases. Here is an example of the different purposes I was referring to. If you have an agent (say some middleware agent) that wants to denote some path as tentative, then that is a function of that agent and we don't care how you implement tht functionality inside your agent. But if the NSI architecture needs to exchange path information between agents, then we need a standard NSI Path Object. Again the purpose of the PO is to describe a *path* not to describe the status or purpose of the path. In your example above, I think you overlay Path Object with Connection Object ...they are not te same.
I do see paths being specified in differing degrees of detail. For example, a user may specify a loose PO that has three hops: ingress, intermediate STP, and the egress. However, by the time the connection is provisioned that PO may be substantially larger and more complex as there are now dozens of STPs - some in opaque POs - that go into the "as-built" PO. Here again, whether the PO is strict or loose or a mix does not really affect how we describe the path itself. In this example, the "connection object" may indicate a lot more information about the resources along the path than the PO itself carries. This is interesting -- I think Vangelis suggested that Connection add info separately to path, not replace it.
I think our PO is close to the ERO of GMPLS - but things like hops pointing to other path objects takes it a bit further. I don't think we should assume or favor any intradomain protocol or architecture. I suggest we focus on what NSI needs to function as a complete architecture, and let specific code implementations handle any protovcol conversion necessary. I think that being able to use GMPLS, unless it is a demonstrable burden, is a good goal. It may require using only a subset of the
AH - what is the difference. I certainly have overlaid them and i have assumed that a path would be used to describe the connection, hence a connection is a set of path objects. path capabilities somehow, but being able to use it would mean that reservation and implementation could be separated and implementation could be done by existing means. If nothing else it helps to keep us honest.
5) Does a path object include a pointer to the agent that could or has authorized it? This seems a crucial question and determines if that info must be provided outside the path via some sort of db. I realize that if it is included it might also have such a db, but it could be searched once, especially in the chain-like implementations of provider agents.
Why would this be crucial to be in the PO? I think you are trying to make the Path Object into a Connection Object which would almost certainly contain considerably more information. A conncetion is typically bidirectional, carries all types of *connection related* parameters including authorization credntials, probably monitoring hooks/pointers, etc. The "Path Object" is just the path. Maybe we should discuss what a "connection object" should be ?...
I am trying to make it a connection object. I guess I don't understand the difference :( Perhaps you could describe the difference ?? Sorry -- John
-- John
On Jan 25, 2010, at 8:51 AM, Jerry Sobieski wrote:
Hi Jeroen-
Hmm... I had always assumed that this would be implicit - that a strict hop PO and Loose hop PO would not really look any different.... But honestly I had not considered whther this was necessary or not. My thought was that whatever agent was using the Path Object would need to check it against the topology anyway - in essence perform a Path Computation between Hop(n) and Hop(n +1). If they are adjacent, this would be an almost zero cost check, and if they were not adjacent, a Path Comp would be needed anyway. I don't know that being explicit relieves any agent from checking adjacency, but there may be some error conditions that are detected if the expectation is explicit in some way. There may be a need to indicate when a hop was/is expected to be adjacent (e.g. a strict hop "as-built" PO that describes a provisioned path after the fact vs a reserved PO that may or may not be strict)
This also brings up the issue of whether the underlying topology can change between when a Path Object is created and when that Path Object is referenced/used. I.e. What happens if a specified hop no longer exists? Or if additional switching points are introduced between say when a reservation is created, and when the connection is provisioned?
I don't think I have a position on the question to making strict vs loose explicit - it might be useful or necessary. Or it may be superfluous. Would we specify each particular hop as strict or loose? Or simply indicate the entire PO as strict or loose? (I'd say hop by hop would be best). Perhaps we allow for a boolean indicator on each hop that says this is "strict hop" to previous hop. If it is not set it could be eiterh loose or strict, but if it *is* set, then the hop must be strict.
Also, as we discuss this, we must formulate what we mean by "adjacent". IMO, adjacent means adjacent in terms of provisioning - i.e. nominally, a switching point that must be re-configured as part of provisioning is a hop that should be presnt in a strict hop PO. If a switching point exists only as part of an underlying tunnel connection, and it is not seen as part of the Path Finding process and not reconfigured as part of a connection's provisioning process, then it is not part of the PO.
For example, a Ethernet link established between Cern and Argonne would be seen as a single link in the topology when allocating Layer2 connections. While there may be lots of switching points that went into setting up that express Etehrnet connection, as far as the Path Finder is concerend, there is one ethernet STP in Cern and one in Argonne, and so provisioning a path between Cern and US over that link would not indicate all those lower layer switching SDH and Wave and Fiber switching points. None of them were reconfigured as part of a connectionusing that long link. However, if a connection is built that adapts the PDU from an Ethernet VLAN into a GFP payload on a sonet link, then that adaptation point is something that is visible to the Path Finder in the topology and is something that is reconfigured to establsih the connection - the Ethernet egress and the GFP ingress STPs are specifically part of the circuit and should be in a strict hop PO. To be complete, that long express Ethernet link would have a strict PO, but it would be associated with that a connection request from another agent somewhere, not with any particular connection riding over the top of it at the time.
THis is probably clear as mud, (:-) but I hope this is useful.
Jerry
Jeroen van der Ham wrote:
On 20/01/2010 20:24, Jerry Sobieski wrote:
- A "partially specified" path identifies a subset of STPs - in order - that the connection transits - but not necessarily every STP the connection transits. THis is a "loose hop" path
Do you propose to make this implicit or explicit? That is, is there a "loose hop" object/marker in the STP?
I would think that some kind of marker is required in order to make this work, and clear to the other parties that part of the STP is hidden.
The loose hop object could also be used to specify whether the "loose" resources have been provisioned, or not, and to specify other kinds of information about the possible path there.
Jeroen. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
This is very good discussion, look forward to continuing this tomorrow morning. Some comments inline: On Jan 26, 2010, at 12:08 PM, John Vollbrecht wrote:
Jerry - thanks again -- good discussion - we might continue tomorrow on call.
comments in line below --
On Jan 26, 2010, at 1:16 PM, Jerry Sobieski wrote:
Some thoughts/comments in line...
John Vollbrecht wrote:
Hi Jerry -
Thanks for doing this -- I am guessing it will generate a lot of discussion, but that is good. I have a number of questions and comments on thinking about this.
1) I would think that there is a difference in loose hop and strict hop if loose hop is optional and strict hop is not.
Not sure what you mean here... From Jeroen's comments, we might have two indicator bits: one that says "This hop is strict", and a second that says "This hop is required". The former means that this hop should be and is expected to be adjacent to the previous hop within the service transport layer.
So adjacent needs to be defined. Do you mean ordered, in the sense that other hops might be inserted but the order must be correct? This might be the case where a high level set of POs might be requested and these might later include lower (hierarchically) paths. Or is there a definition of adjacent that requires lowest level POs (and what is lowest)?
Since NSI is a cross-domain protocol (NRM manages intra-domain pathfinding and setup), I imagine that the client or a neighboring NSA (using older terminology) in NSI will specify ingress and egress STPs for the domain in case of strict hops. A loose hop will then be when an intervening domain is not specified or if ingress into a domain is specified but egress is not, or any other omission. When the path is fully instantiated, it is possible that the full end-to-end ERO may be accessible by management stations, monitoring services and possibly, the client.
The latter would mean that if this hop is not available, at some point when the PO is referenced, then an error condition should be raised (the alternative is to ignore the hop). I don't think we need the "required" bit - if the hop is in the PO, it is implied to be required (IMO). The "strict" bit probably would be useful, but we should discuss what it means for a hop that is actually a reference toa subpath object. Required might be similar to the first definition above.
2) I am wondering if strict hop for NSI purposes includes ingress and egress from resources controlled by NRM. NRM is the atomic controller for the resource. Even an opaque topology must still have edge points that interface with the rest of the universe. Those edge egress STPs must be linked to specific ingress STPs on the other side of the link so that connections can be progressed across specific interdomain links. So, a remote domain would reveal its edge STPs that serve me, but maybe not others. I may never see and edge STP on the far side of a transit domain. Whether a domain reveals the ingress and egress STPs in a PO is up to the domain. If it does not, there may be difficulties for interactions with domains further downstream, but it should not affect most things (I think).
Actually this raises a point I am worrying about -- does a STP exist on both connections that are concatenated, or is a STP the place where they are concatenated? I also wonder about how this plays with instantiation and monitoring of a connection on a path. Presumably path is required for these as well as request.
There is a confusion on STP: I feel STPs should represent end-to-end service terminations based on the client's perspective. This recursively carries over within a multi-domain when a NSA/service requestor is a client of another domain. It would make better sense to have STPs that exist on both connections that are concatenated.
3) For some requests the NRM may not want to be advertised/ known by all other NRMs. Is that possible? I do not think the Path Object should reference the NRM or NSAs at all. The PO references *only* points in the topology to describe a path - nothing more. I am pretty adamant about this because the PO will likely be used for a number of differnet purposes - we don't want it to duplicate information for every possible purpose - information that is best maintained elsewhere...and I think the mapping between an STP and the NSA/NRM is best maintained someplace more authoritative.
any ideas of where? I think this is an ok answer, but would like to have an alternative if its not there.
The fact that you are identifying the domain/sub-domain within the URI will identify the associated NRM through some lookup mechanism. So indirectly the path object would refer to a NRM?
However (:-), it *is* necessary that there be an explicit means within the NSI architecture for STP identifiers (service locations) to be mapped to domains in which they reside, relevant NSAs and/or NRMs, policy, etc. But since this will be done for lots of different reasons, I think it should be an explicitly defined aspect of the architecture and an explicit separate service from the NSI Connection Service.
ok - as noted above
I personally like the notion of a URI style name for STPs and POs. An named object should be of the form //<domain>/<subdomain>... /<name>, ala "//Allen/A" where A is the endpoint name, and everything in front is a domain identifier. This makes the domain obvious and explicit for an STP or PO or other object. There are some still soe open issues on this, but we do need this fundamental mapping from <endpoint name> to <location in global topology> that has to happen somehow.... Also, I think the population and maintanence of the name resolution service must be distributed and automated.
at least defined. I happen to think that for some deployments it might be fairly small and static and could be just a table in an agent.
4) I would think that a path might be "tentative" vs configured - tentative being a request and possibly including some options and configured being what is reserved/ granted to the requestor. I am also thinking that what is configured might be used directly by GMPLS implementations if GMPLS is supported on all resources. It might also be used in NSI provisioning requests. I wonder if it would look different in those different cases. Here is an example of the different purposes I was referring to. If you have an agent (say some middleware agent) that wants to denote some path as tentative, then that is a function of that agent and we don't care how you implement tht functionality inside your agent. But if the NSI architecture needs to exchange path information between agents, then we need a standard NSI Path Object. Again the purpose of the PO is to describe a *path* not to describe the status or purpose of the path. In your example above, I think you overlay Path Object with Connection Object ...they are not te same.
AH - what is the difference. I certainly have overlaid them and i have assumed that a path would be used to describe the connection, hence a connection is a set of path objects.
I think connection will have other parameters than just path. Connection will have time of expiry, bandwidth, etc. Path object does not carry information on the connection like capacity, deadlines, policy etc.
I do see paths being specified in differing degrees of detail. For example, a user may specify a loose PO that has three hops: ingress, intermediate STP, and the egress. However, by the time the connection is provisioned that PO may be substantially larger and more complex as there are now dozens of STPs - some in opaque POs - that go into the "as-built" PO. Here again, whether the PO is strict or loose or a mix does not really affect how we describe the path itself. In this example, the "connection object" may indicate a lot more information about the resources along the path than the PO itself carries. This is interesting -- I think Vangelis suggested that Connection add info separately to path, not replace it.
I think our PO is close to the ERO of GMPLS - but things like hops pointing to other path objects takes it a bit further. I don't think we should assume or favor any intradomain protocol or architecture. I suggest we focus on what NSI needs to function as a complete architecture, and let specific code implementations handle any protovcol conversion necessary. I think that being able to use GMPLS, unless it is a demonstrable burden, is a good goal. It may require using only a subset of the path capabilities somehow, but being able to use it would mean that reservation and implementation could be separated and implementation could be done by existing means. If nothing else it helps to keep us honest.
5) Does a path object include a pointer to the agent that could or has authorized it? This seems a crucial question and determines if that info must be provided outside the path via some sort of db. I realize that if it is included it might also have such a db, but it could be searched once, especially in the chain-like implementations of provider agents.
Why would this be crucial to be in the PO? I think you are trying to make the Path Object into a Connection Object which would almost certainly contain considerably more information. A conncetion is typically bidirectional, carries all types of *connection related* parameters including authorization credntials, probably monitoring hooks/pointers, etc. The "Path Object" is just the path. Maybe we should discuss what a "connection object" should be ?...
I am trying to make it a connection object. I guess I don't understand the difference :( Perhaps you could describe the difference ?? Sorry --
John
-- John
On Jan 25, 2010, at 8:51 AM, Jerry Sobieski wrote:
Hi Jeroen-
Hmm... I had always assumed that this would be implicit - that a strict hop PO and Loose hop PO would not really look any different.... But honestly I had not considered whther this was necessary or not. My thought was that whatever agent was using the Path Object would need to check it against the topology anyway - in essence perform a Path Computation between Hop(n) and Hop(n+1). If they are adjacent, this would be an almost zero cost check, and if they were not adjacent, a Path Comp would be needed anyway. I don't know that being explicit relieves any agent from checking adjacency, but there may be some error conditions that are detected if the expectation is explicit in some way. There may be a need to indicate when a hop was/is expected to be adjacent (e.g. a strict hop "as-built" PO that describes a provisioned path after the fact vs a reserved PO that may or may not be strict)
This also brings up the issue of whether the underlying topology can change between when a Path Object is created and when that Path Object is referenced/used. I.e. What happens if a specified hop no longer exists? Or if additional switching points are introduced between say when a reservation is created, and when the connection is provisioned?
I don't think I have a position on the question to making strict vs loose explicit - it might be useful or necessary. Or it may be superfluous. Would we specify each particular hop as strict or loose? Or simply indicate the entire PO as strict or loose? (I'd say hop by hop would be best). Perhaps we allow for a boolean indicator on each hop that says this is "strict hop" to previous hop. If it is not set it could be eiterh loose or strict, but if it *is* set, then the hop must be strict.
Also, as we discuss this, we must formulate what we mean by "adjacent". IMO, adjacent means adjacent in terms of provisioning - i.e. nominally, a switching point that must be re-configured as part of provisioning is a hop that should be presnt in a strict hop PO. If a switching point exists only as part of an underlying tunnel connection, and it is not seen as part of the Path Finding process and not reconfigured as part of a connection's provisioning process, then it is not part of the PO.
For example, a Ethernet link established between Cern and Argonne would be seen as a single link in the topology when allocating Layer2 connections. While there may be lots of switching points that went into setting up that express Etehrnet connection, as far as the Path Finder is concerend, there is one ethernet STP in Cern and one in Argonne, and so provisioning a path between Cern and US over that link would not indicate all those lower layer switching SDH and Wave and Fiber switching points. None of them were reconfigured as part of a connectionusing that long link. However, if a connection is built that adapts the PDU from an Ethernet VLAN into a GFP payload on a sonet link, then that adaptation point is something that is visible to the Path Finder in the topology and is something that is reconfigured to establsih the connection - the Ethernet egress and the GFP ingress STPs are specifically part of the circuit and should be in a strict hop PO. To be complete, that long express Ethernet link would have a strict PO, but it would be associated with that a connection request from another agent somewhere, not with any particular connection riding over the top of it at the time.
THis is probably clear as mud, (:-) but I hope this is useful.
Jerry
Jeroen van der Ham wrote:
On 20/01/2010 20:24, Jerry Sobieski wrote:
- A "partially specified" path identifies a subset of STPs - in order - that the connection transits - but not necessarily every STP the connection transits. THis is a "loose hop" path
Do you propose to make this implicit or explicit? That is, is there a "loose hop" object/marker in the STP?
I would think that some kind of marker is required in order to make this work, and clear to the other parties that part of the STP is hidden.
The loose hop object could also be used to specify whether the "loose" resources have been provisioned, or not, and to specify other kinds of information about the possible path there.
Jeroen. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hi John- I am deleting some of the text to make the email a bit more readable... John Vollbrecht wrote:
Jerry wrote: Not sure what you mean here... From Jeroen's comments, we might have two indicator bits: one that says "This hop is strict", and a second that says "This hop is required". The former means that this hop should be and is expected to be adjacent to the previous hop within the service transport layer.
So adjacent needs to be defined. Do you mean ordered, in the sense that other hops might be inserted but the order must be correct? This might be the case where a high level set of POs might be requested and these might later include lower (hierarchically) paths. Or is there a definition of adjacent that requires lowest level POs (and what is lowest)?
"Adjacent" means "directly next to each other." I will get pedantic now(:-): Two vertices in a graph are adjacent if they are connected by an edge. Within our network topology model, two Nodes, A and B, are /adjacent/ if there exists a Link in the toplogy that has one endpoint on A and the other endpoint on B. A Link, which represents an immutable transparent transport conduit between two Nodes in the topology, by definition, establishes adjacency between those two nodes. In the PO, a "strict" hop means simply that the path from hop(k) to hop(k+1) transits no (zero) intervening nodes. i.e. hop(k) and hop(k+1) should be or are expected to be /adjacent/ in the topology. The latter hop, the k+1 hop in this example, would be flagged as "strict" in this case. In the PO, the order of the hops is important, but the strict/loose tagging only implies something about the possible presence or absence of intervening nodes. To be clear about adjacency, if a Link in the topology is realized over lower layer infrastructure - even if that infrastructure itself is part of the topologyDB - the Link still constitutes adjacency since the underlying supporting infrastructure is transparent to the layer at which the Link is defined in the topology (i.e. the nodes it connects). This allows us, for example, to allocate a GFP/SDH circuit over an SDH cloud and define the resulting ethernet connection in the topology as an Ethernet Link forming an adjacency between two Ethernet Nodes. Jerry
The big issue with this in my mind is that adjacency as you define depends on a particular topology. If the topology is hierarchical or perhaps different for different providers, then what is adjacent for one may not be adjacent for another. I don't think we want to define topology in order to define what we mean by path terms, at least if we can avoid it. Does that make sense? John On Jan 27, 2010, at 8:36 PM, Jerry Sobieski wrote:
Hi John-
I am deleting some of the text to make the email a bit more readable...
John Vollbrecht wrote:
Jerry wrote: Not sure what you mean here... From Jeroen's comments, we might have two indicator bits: one that says "This hop is strict", and a second that says "This hop is required". The former means that this hop should be and is expected to be adjacent to the previous hop within the service transport layer.
So adjacent needs to be defined. Do you mean ordered, in the sense that other hops might be inserted but the order must be correct? This might be the case where a high level set of POs might be requested and these might later include lower (hierarchically) paths. Or is there a definition of adjacent that requires lowest level POs (and what is lowest)?
"Adjacent" means "directly next to each other." I will get pedantic now(:-): Two vertices in a graph are adjacent if they are connected by an edge. Within our network topology model, two Nodes, A and B, are adjacent if there exists a Link in the toplogy that has one endpoint on A and the other endpoint on B. A Link, which represents an immutable transparent transport conduit between two Nodes in the topology, by definition, establishes adjacency between those two nodes.
In the PO, a "strict" hop means simply that the path from hop(k) to hop(k+1) transits no (zero) intervening nodes. i.e. hop(k) and hop(k +1) should be or are expected to be adjacent in the topology. The latter hop, the k+1 hop in this example, would be flagged as "strict" in this case. In the PO, the order of the hops is important, but the strict/loose tagging only implies something about the possible presence or absence of intervening nodes.
To be clear about adjacency, if a Link in the topology is realized over lower layer infrastructure - even if that infrastructure itself is part of the topologyDB - the Link still constitutes adjacency since the underlying supporting infrastructure is transparent to the layer at which the Link is defined in the topology (i.e. the nodes it connects). This allows us, for example, to allocate a GFP/SDH circuit over an SDH cloud and define the resulting ethernet connection in the topology as an Ethernet Link forming an adjacency between two Ethernet Nodes.
Jerry
John Vollbrecht wrote:
The big issue with this in my mind is that adjacency as you define depends on a particular topology. If the topology is hierarchical or perhaps different for different providers, then what is adjacent for one may not be adjacent for another. I don't think we want to define topology in order to define what we mean by path terms, at least if we can avoid it. Does that make sense?
John
Hey John- Two points: a) The adjacency definition still works even for hierarchical topologies. b) you cannot describe a "path" without some model of the topology (or graph) over which that path exists. If two nodes are connected by a link, then they are adjacent. By Definition. This comes from our definition of a Link as being an edge in the topology graph and representing a "connection" between two nodes. How you define the nodes or what topology they may hide/summarize is immaterial. And whether that link is predicated over some underlying infrastructure is also immateral. In practice, a "hierarchical" node simply hides its internal topology and only expresses itself as a single virtual node (or a set of virtual nodes nodes with some abstracted topology.) From a topological perspective, those virtual nodes are still "nodes" and still have "links" to other nodes. And so, that virtual node is still adjacent to the other nodes at the ends of those links. That single virtual node must still be consulted in order to reserve a path though it. (Of course the NSA (or NRM) responsible for that virtual node must still consult the internal nodes that comprise the opaque internal topology - but that is invisible to the external agents.) Even in our multi-layer networks, adjacency is still defined by the existence of a link between two nodes. The only precondition on this is that the link between those two nodes imposes no requirements on tours (pathfinding) through the topology. In reality, the topology must often express more detail than simply physical hardware boxes - for instance, a Ciena CoreDirector would be expressed as several nodes in the topology - perhaps summarized into a single virtual node, but the pathfinding process must still consider, at some level, the functional elements/resources that exist inside the physical box (virtual node) that are necessary for establishing a connection through the node. Indeed, we may need to define totally virtual topological elements that represent protocol conversions and adaptations if path finding is to work end to end...but this can still be done within a very simple graph oriented, possibly hierarchical, topology model. So, for NSI's part, we *do* need to make some assertions about how the NSAs relate to topology. This will require a topology model. IMO this should be a very simple high evel model, but one that nevertheless is very generalized and can scale well. Details of the topology database or the syntax or structure of a topology description or distribution processes are not our role...but the basic topology environment in which we expect the NSA to operate is within scope. If PathFinding is a concern for NSI, then we must necessarilly have some topological model that we subscribe to. Topology and PathFInding are intricately linked - you can not speak of one without some implications for the other. For instance, we can not even begin to discuss Tree vs Chain models without some assumptions about topology. What are those assumptions? We must stipulate a knowledge of and/or responsibility for some portion of the topology if we expect the NSA to do anything of substance. And if you have anything less that one global Master Control NSA, then you introduce issues about how two or more NSA would interact to effect a global service - which again implies something about topology. So NSI Architecture is fundamentally dependent upon some basic topology model - we should define and describe that model and then describe how the NSI protocol(s) operate in the context of that model. Not to put too fine a point on this, even just specifying End Points for a connection request stipulates some notion of topology. What is an "End Point" or a "Service Termination Point"? Even just deciding if an STP is in our domain or a foreign domain implies some concept of what the topology looks like and how it functions... Making any intelligent decision about breaking a connection request into component segments requires some knowledge of topology. So what topological properties are necessary to allow the NSA to function in this manner? We really can't talk about Paths or PathFinding without some associated topology model. So in closing, we should perhaps have a section in the NSI Architecture doc that clearly and succinctly describes the contextual topology model over which the NSI is defined and operates. This needn't be a long section, and should be fairly high level, but I think explicitly describing the topo model allows us to describe how NSAs and NRM and STPs relate to the transport plane we purport to manage. Thoughts? Jerry
On Jan 27, 2010, at 8:36 PM, Jerry Sobieski wrote:
Hi John-
I am deleting some of the text to make the email a bit more readable...
John Vollbrecht wrote:
Jerry wrote: Not sure what you mean here... From Jeroen's comments, we might have two indicator bits: one that says "This hop is strict", and a second that says "This hop is required". The former means that this hop should be and is expected to be adjacent to the previous hop within the service transport layer.
So adjacent needs to be defined. Do you mean ordered, in the sense that other hops might be inserted but the order must be correct? This might be the case where a high level set of POs might be requested and these might later include lower (hierarchically) paths. Or is there a definition of adjacent that requires lowest level POs (and what is lowest)?
"Adjacent" means "directly next to each other." I will get pedantic now(:-): Two vertices in a graph are adjacent if they are connected by an edge. Within our network topology model, two Nodes, A and B, are /adjacent/ if there exists a Link in the toplogy that has one endpoint on A and the other endpoint on B. A Link, which represents an immutable transparent transport conduit between two Nodes in the topology, by definition, establishes adjacency between those two nodes.
In the PO, a "strict" hop means simply that the path from hop(k) to hop(k+1) transits no (zero) intervening nodes. i.e. hop(k) and hop(k+1) should be or are expected to be /adjacent/ in the topology. The latter hop, the k+1 hop in this example, would be flagged as "strict" in this case. In the PO, the order of the hops is important, but the strict/loose tagging only implies something about the possible presence or absence of intervening nodes.
To be clear about adjacency, if a Link in the topology is realized over lower layer infrastructure - even if that infrastructure itself is part of the topologyDB - the Link still constitutes adjacency since the underlying supporting infrastructure is transparent to the layer at which the Link is defined in the topology (i.e. the nodes it connects). This allows us, for example, to allocate a GFP/SDH circuit over an SDH cloud and define the resulting ethernet connection in the topology as an Ethernet Link forming an adjacency between two Ethernet Nodes.
Jerry
So in closing, we should perhaps have a section in the NSI Architecture doc that clearly and succinctly describes the contextual topology model over which the NSI is defined and operates. This needn't be a long section, and should be fairly high level, but I think explicitly describing the topo model allows us to describe how NSAs and NRM and STPs relate to the transport plane we purport to manage. Thoughts?
My assumption had been that these are well understood concepts that need not have a separate section, but now I feel a high-level description is warranted. It would be good to supplement it with external references.
In practice, a "hierarchical" node simply hides its internal topology and only expresses itself as a single virtual node (or a set of virtual nodes nodes with some abstracted topology.) From a topological perspective, those virtual nodes are still "nodes" and still have "links" to other nodes. And so, that virtual node is still adjacent to the other nodes at the ends of those links. That single virtual node must still be consulted in order to reserve a path though it. (Of course the NSA (or NRM) responsible for that virtual node must still consult the internal nodes that comprise the opaque internal topology - but that is invisible to the external agents.)
This is how the implementation was in the DRAC project I was involved with. Multi-layer path-finding is implemented in this context as well - intermediate topology of a lower layer can be abstracted as a virtual node or link at a higher layer. Usually in today's networks, since the layers are fixed/provisioned, narrowing down to an optimal path, within a particular contextual topology is easier. When these multi-layers have agility i.e. topology can be changed on demand at each layer, that is when the optimal path decision process becomes quite complex. In this situation full-understanding and representation of the capabilities and constraints of the virtual nodes within the topological model becomes required. This is a research topic in itself and I would not want to go in such detail in the architecture spec. Inder
Jerry
On Jan 27, 2010, at 8:36 PM, Jerry Sobieski wrote:
Hi John-
I am deleting some of the text to make the email a bit more readable...
John Vollbrecht wrote:
Jerry wrote: Not sure what you mean here... From Jeroen's comments, we might have two indicator bits: one that says "This hop is strict", and a second that says "This hop is required". The former means that this hop should be and is expected to be adjacent to the previous hop within the service transport layer.
So adjacent needs to be defined. Do you mean ordered, in the sense that other hops might be inserted but the order must be correct? This might be the case where a high level set of POs might be requested and these might later include lower (hierarchically) paths. Or is there a definition of adjacent that requires lowest level POs (and what is lowest)?
"Adjacent" means "directly next to each other." I will get pedantic now(:-): Two vertices in a graph are adjacent if they are connected by an edge. Within our network topology model, two Nodes, A and B, are adjacent if there exists a Link in the toplogy that has one endpoint on A and the other endpoint on B. A Link, which represents an immutable transparent transport conduit between two Nodes in the topology, by definition, establishes adjacency between those two nodes.
In the PO, a "strict" hop means simply that the path from hop(k) to hop(k+1) transits no (zero) intervening nodes. i.e. hop(k) and hop(k+1) should be or are expected to be adjacent in the topology. The latter hop, the k+1 hop in this example, would be flagged as "strict" in this case. In the PO, the order of the hops is important, but the strict/loose tagging only implies something about the possible presence or absence of intervening nodes.
To be clear about adjacency, if a Link in the topology is realized over lower layer infrastructure - even if that infrastructure itself is part of the topologyDB - the Link still constitutes adjacency since the underlying supporting infrastructure is transparent to the layer at which the Link is defined in the topology (i.e. the nodes it connects). This allows us, for example, to allocate a GFP/SDH circuit over an SDH cloud and define the resulting ethernet connection in the topology as an Ethernet Link forming an adjacency between two Ethernet Nodes.
Jerry
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
participants (5)
-
Inder Monga -
Jeroen van der Ham -
Jerry Sobieski -
Joan A. Garcia-Espin -
John Vollbrecht