Attached is set of ppt slides to describe interdomain topology. I hope this helps - it is based on conversations in the NML group, and is my understanding of what the Glossary of terms that Guy is reviewing (and I think will review next Wed). I will be on vacation in Israel for the next couple weeks, and I don't expect to get much internet access. Perhaps some, but I don't count on it. I will be back and would like to have a call the week before OGF, and I will be there. I hope this helps. I think it needs to be discussed with NML group after it is is discussed in NSI. John
On 21/02/2010 18:20, John Vollbrecht wrote:
Attached is set of ppt slides to describe interdomain topology. I hope this helps - it is based on conversations in the NML group, and is my understanding of what the Glossary of terms that Guy is reviewing (and I think will review next Wed).
I just want to clarify my view of the conversation we have had in the NML group about this issue. This was mainly a discussion between myself and John wherein I tried to understand the NSI issue of describing inter-domain topologies. The current NML topology model does not have "Points". Nor do we currently have plans to add them. *Unless* there is a use-case showing the need of Points, which clearly outlines why it is not possible to describe domain boundaries with the current NML Topology model. So far, I have not seen such a clear and valid use-case for "Points". Jeroen.
Jeroen, If we put aside the question of point vs port naming for the moment, I think that John's slides raise an important question. This is how best to describe connectivity between networks. One option is to carry over the exiting NML concepts and assign a link as the connection between two networks. In this case the link will have to be 'un-owned' i.e. it is not within the control or ownership of either network. The alternative option presented by John is to use a port or point concept to joint two ports on adjacent networks. In this case there are no objects (i.e links) between networks - this solves the problem of un-owned resources. To understand the implications of the existing NML model better, lets take the example of a fibre that connects two Ethernet switches in adjacent racks. In this case I expect that the NML model will nominate the two Ethernet ports on the switches as 'Ports' and the fibre as a 'Link'. In this example it might be possible to replace the fibre with a transatlantic wavelength leased by one of the end networks. The question in my mind is how we allocate ownership of the inter-domain 'link'. If we follow John's model and insist that there are no resources that are 'un-owned', then we need to allow the modelling of connectors that do not belong to switches. So going back to my previous example, the demarcation point between networks moves from the Ethernet ports on the switches to a connector on a distribution frame that marks the boundary of physical ownership between the two networks. In other words the schema would model the demarcation point between networks in a much more literal physical way. The question in my mind is whether there is a real use-case for the second model. Does NSI need to model the demarcation of ownership of items in the inter-network space, eg wavelengths or patch chords between providers? This is a interesting question and needs a very clearly documented use-case. Guy -----Original Message----- From: Jeroen van der Ham [mailto:vdham@uva.nl] Sent: 21 February 2010 21:08 To: John Vollbrecht Cc: NSI WG Subject: Re: [Nsi-wg] NML topology On 21/02/2010 18:20, John Vollbrecht wrote:
Attached is set of ppt slides to describe interdomain topology. I hope this helps - it is based on conversations in the NML group, and is my understanding of what the Glossary of terms that Guy is reviewing (and I think will review next Wed).
I just want to clarify my view of the conversation we have had in the NML group about this issue. This was mainly a discussion between myself and John wherein I tried to understand the NSI issue of describing inter-domain topologies. The current NML topology model does not have "Points". Nor do we currently have plans to add them. *Unless* there is a use-case showing the need of Points, which clearly outlines why it is not possible to describe domain boundaries with the current NML Topology model. So far, I have not seen such a clear and valid use-case for "Points". Jeroen. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hi All, From a practical perspective, links are always "owned." For a zero-cost link at an exchange point, the ownership may be less clear, but even in that case, our perspective has been that the egress part of the unidirectional link is owned by the network/node/port that is driving it. The link itself really has few properties outside of propagation delay and loss, but has addressing and queueing properties that are assigned to the port driving it and that port *always* has an owner. That said, I found John's slides and this point to be interesting and thought- provoking. But I would still encourage things to be expressed to the NML in terms of requirements rather than terminology. There are ports and links and they are owned (at least by my definition above). In the described case, there are different policies that need to be applied for inter-domain links and ports that dynamic. I still don't think that we need a new a "thing" to describe the same old "thing" with different roles and policies. best, martin On Feb 22, 2010, at 6:00 AM, Guy Roberts wrote:
Jeroen,
If we put aside the question of point vs port naming for the moment, I think that John's slides raise an important question. This is how best to describe connectivity between networks.
One option is to carry over the exiting NML concepts and assign a link as the connection between two networks. In this case the link will have to be 'un-owned' i.e. it is not within the control or ownership of either network.
The alternative option presented by John is to use a port or point concept to joint two ports on adjacent networks. In this case there are no objects (i.e links) between networks - this solves the problem of un-owned resources.
To understand the implications of the existing NML model better, lets take the example of a fibre that connects two Ethernet switches in adjacent racks. In this case I expect that the NML model will nominate the two Ethernet ports on the switches as 'Ports' and the fibre as a 'Link'. In this example it might be possible to replace the fibre with a transatlantic wavelength leased by one of the end networks. The question in my mind is how we allocate ownership of the inter-domain 'link'.
If we follow John's model and insist that there are no resources that are 'un-owned', then we need to allow the modelling of connectors that do not belong to switches. So going back to my previous example, the demarcation point between networks moves from the Ethernet ports on the switches to a connector on a distribution frame that marks the boundary of physical ownership between the two networks. In other words the schema would model the demarcation point between networks in a much more literal physical way.
The question in my mind is whether there is a real use-case for the second model. Does NSI need to model the demarcation of ownership of items in the inter-network space, eg wavelengths or patch chords between providers? This is a interesting question and needs a very clearly documented use-case.
Guy
-----Original Message----- From: Jeroen van der Ham [mailto:vdham@uva.nl] Sent: 21 February 2010 21:08 To: John Vollbrecht Cc: NSI WG Subject: Re: [Nsi-wg] NML topology
On 21/02/2010 18:20, John Vollbrecht wrote:
Attached is set of ppt slides to describe interdomain topology. I hope this helps - it is based on conversations in the NML group, and is my understanding of what the Glossary of terms that Guy is reviewing (and I think will review next Wed).
I just want to clarify my view of the conversation we have had in the NML group about this issue. This was mainly a discussion between myself and John wherein I tried to understand the NSI issue of describing inter-domain topologies.
The current NML topology model does not have "Points". Nor do we currently have plans to add them. *Unless* there is a use-case showing the need of Points, which clearly outlines why it is not possible to describe domain boundaries with the current NML Topology model. So far, I have not seen such a clear and valid use-case for "Points".
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
On 22/02/2010 12:29, Martin Swany wrote:
From a practical perspective, links are always "owned." For a zero-cost link at an exchange point, the ownership may be less clear, but even in that case, our perspective has been that the egress part of the unidirectional link is owned by the network/node/port that is driving it. The link itself really has few properties outside of propagation delay and loss, but has addressing and queueing properties that are assigned to the port driving it and that port *always* has an owner.
How would that apply to a fiber that is connected to an open exchange (e.g. GOLE)? The port on that exchange would be owned by the network connecting to that exchange. So would the unidirectional link *to* the exchange. Who would own the unidirectionl link *from* the exchange? Jeroen.
I would like to propose something for discussion. I realize this may not be "the" answer, but I am hoping it can generate some discussion that will help us come to a good coordination of NML and NSI requirements - which I think are pretty close but not totally matched yet. A couple comments about viewpoints - NML is mostly concerned with topology and path finding requirements (not exclusively I understand) NSI is mostly concerned with ownership and authorization NML and deals with networking units basically nodes and links NSI deals with sets of networking units owned by a NRM - it call these sets networks A NSI network can be describe as a NML group specifically owned by an NRM - I don't think there is any problem with this. Nodes and links can have owners in NML. NSI network could be considered a hierarchical "node". However NRMs own links as well as nodes, and no NRM link exists outside a network. So - the proposal so far is to call the edge of a network a port, and a port may be on a NML node or link. This is a problem because NML links don't have ports, so the proposal is to allow links to have ports. How this helps is that now topology for pathfinding can be described between nodes over links without worrying about ownership, and reservation can be done using resources without worrying about topology between networks. Some discussion of whether a link is described with ends independent of nodes for resource purposes and if the ends are actually ports might be helpful (or not). At any rate, I think it would be good to discuss the problem and possible solutions at OGF. John On Feb 22, 2010, at 6:29 AM, Martin Swany wrote:
Hi All,
From a practical perspective, links are always "owned." For a zero- cost link at an exchange point, the ownership may be less clear, but even in that case, our perspective has been that the egress part of the unidirectional link is owned by the network/node/port that is driving it. The link itself really has few properties outside of propagation delay and loss, but has addressing and queueing properties that are assigned to the port driving it and that port *always* has an owner.
That said, I found John's slides and this point to be interesting and thought- provoking. But I would still encourage things to be expressed to the NML in terms of requirements rather than terminology. There are ports and links and they are owned (at least by my definition above). In the described case, there are different policies that need to be applied for inter- domain links and ports that dynamic. I still don't think that we need a new a "thing" to describe the same old "thing" with different roles and policies.
best, martin
On Feb 22, 2010, at 6:00 AM, Guy Roberts wrote:
Jeroen,
If we put aside the question of point vs port naming for the moment, I think that John's slides raise an important question. This is how best to describe connectivity between networks.
One option is to carry over the exiting NML concepts and assign a link as the connection between two networks. In this case the link will have to be 'un-owned' i.e. it is not within the control or ownership of either network.
The alternative option presented by John is to use a port or point concept to joint two ports on adjacent networks. In this case there are no objects (i.e links) between networks - this solves the problem of un-owned resources.
To understand the implications of the existing NML model better, lets take the example of a fibre that connects two Ethernet switches in adjacent racks. In this case I expect that the NML model will nominate the two Ethernet ports on the switches as 'Ports' and the fibre as a 'Link'. In this example it might be possible to replace the fibre with a transatlantic wavelength leased by one of the end networks. The question in my mind is how we allocate ownership of the inter-domain 'link'.
If we follow John's model and insist that there are no resources that are 'un-owned', then we need to allow the modelling of connectors that do not belong to switches. So going back to my previous example, the demarcation point between networks moves from the Ethernet ports on the switches to a connector on a distribution frame that marks the boundary of physical ownership between the two networks. In other words the schema would model the demarcation point between networks in a much more literal physical way.
The question in my mind is whether there is a real use-case for the second model. Does NSI need to model the demarcation of ownership of items in the inter-network space, eg wavelengths or patch chords between providers? This is a interesting question and needs a very clearly documented use-case.
Guy
-----Original Message----- From: Jeroen van der Ham [mailto:vdham@uva.nl] Sent: 21 February 2010 21:08 To: John Vollbrecht Cc: NSI WG Subject: Re: [Nsi-wg] NML topology
On 21/02/2010 18:20, John Vollbrecht wrote:
Attached is set of ppt slides to describe interdomain topology. I hope this helps - it is based on conversations in the NML group, and is my understanding of what the Glossary of terms that Guy is reviewing (and I think will review next Wed).
I just want to clarify my view of the conversation we have had in the NML group about this issue. This was mainly a discussion between myself and John wherein I tried to understand the NSI issue of describing inter-domain topologies.
The current NML topology model does not have "Points". Nor do we currently have plans to add them. *Unless* there is a use-case showing the need of Points, which clearly outlines why it is not possible to describe domain boundaries with the current NML Topology model. So far, I have not seen such a clear and valid use-case for "Points".
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
John Vollbrecht wrote:
A NSI network can be describe as a NML group specifically owned by an NRM - I don't think there is any problem with this. Nodes and links can have owners in NML.
Note that NML now avoids the word "network" because it is unclear whether the operational grouping or administrative grouping is meant. The NML terminology is as follows: Topology: A set of Network Elements and the links connecting them. NetworkDomain: An unordered collection of Network Elements managed under the same shared policy umbrella.
So - the proposal so far is to call the edge of a network a port
In NMC this is called the demarcation point. I don't thing this concept is yet defined in either NSI or NML, but I propose to re-use this existing name.
This is a problem because NML links don't have ports, so the proposal is to allow links to have ports.
I'm confused here. NML does indeed define ports, they are logical interfaces. In the current definition, they are the things that "connect a Node or a Group to the rest of the network", presumably connecting the Node or Group to a Link.
How this helps is that now topology for pathfinding can be described between nodes over links without worrying about ownership, and reservation can be done using resources without worrying about topology between networks.
Could you elaborate on your specific requirement? While I think this is correct, I was under the impression that this was already possible. Aslo D 3.3: The model must be able to describe resources (ports/points) in a Network that are available for connecting to other Networks. (this is a Network Port) As a last note, you refer to ports and owners in this document. I just had a quick look at the NSI requirement document (https://docs.google.com/Doc?docid=0AZTOJNVUoixhZGZ4cjRiemtfMzQyaGZtOG4yZ2o&hl=en) This document has three design statements related to ports:
D 3.3: The model must be able to describe resources (ports/points) in a Network that are available for connecting to other Networks. (this is a Network Port)I think the *requirement* is that the model must indicate where topologically networks transport planes interconnect. We need to come to a vote/consensus on a model to adopt. This requirement (and many of these) sound more like definitions than requirements. -Jerry Sobieski 2/26/10 10:18 AM
D 3.4: Network Ports must be able to be assigned to the end of a link that is internal to the domain as well as to ports on a device. In my opinion a Network Port on a link requirement needs a use-case -Guy Roberts 2/26/10 3:17 PM Sounds like a definition rather than a requirement-Jerry Sobieski 2/26/10 10:21 AM
D 3.5: The model must be able to describe an arbitrary number of layers of logical ports within a Network Port. Must be able to describe multi-layer networks.
and there is one design statement related to owner:
D 3.8: The resources that make up Network Points must have ownership by a clearly identifiable provider. (i.e. resources without NSA ownership are not allowed). (note: Does this also include the patch cord between providers?) All "resources" in the NSI model *must* map to a single authoritative management agent (NSA). -Jerry Sobieski 2/26/10 10:31 AM
In line with these (inline) comments, a clear requirement would be more beneficial for the NML instead of a definition proposal. For example, I like the requirement on ownership, since it clearly requires a relation between network point and owner, and defines that each network point MUST have exactly one owner. Now all I like to know if this "owner" defines the entity that either *decides* OR *enforces* the policy, and if these may be different entities. If the requirement for Port would be just as clear, I would be very happy. Regards, Freek
Hi Freek, John, All;
John Vollbrecht wrote:
A NSI network can be describe as a NML group specifically owned by an NRM - I don't think there is any problem with this. Nodes and links can have owners in NML.
Note that NML now avoids the word "network" because it is unclear whether the operational grouping or administrative grouping is meant. The NML terminology is as follows:
Topology: A set of Network Elements and the links connecting them.
NetworkDomain: An unordered collection of Network Elements managed under the same shared policy umbrella.
So - the proposal so far is to call the edge of a network a port
In NMC this is called the demarcation point.
Freek: I believe you are confusing a perfSONAR product (e2emon) with documents that are being produced in the OGF NMC-WG. To my knowledge we have never used this term. Thanks; -jason
Jason Zurawski wrote:
So - the proposal so far is to call the edge of a network a port
In NMC this is called the demarcation point.
Freek: I believe you are confusing a perfSONAR product (e2emon) with documents that are being produced in the OGF NMC-WG. To my knowledge we have never used this term.
Jason, as always you are correct. That said, I the name "demarcation point" is a good term for the concept of the edge of an administrative boundary. The edge of a Group or Topology is still a "Port" in NML. Regards, Freek
Hi all, This ownership issue has been lingering above the field already for years. We (mostly Leon Gommans, Freek Dijkstra) studied the ownership models back in 2004-2005. See below for a number of pointers that I recently gathered for another discussion in a new EU project. Although it seems that the ADMINISTRATIVE ownership of a link does not matter if it is used between two networks, it is essential when used towards an open exchange. Exchanges facilitate connectivity between all that arrive at the exchange and do not themselves participate in the policy decision to exchange. But the peers need to participate and therefore the administrative owner of the incoming and the administrative owner of the outgoing link need to agree to exchange. The exchange at best applies device policy (aka for example, I can do 40 gig but not 100 gig between those peers because of lack of hardware capability). See for pointers: ========================= During last weeks meeting regarding WP1 I promised to spread info on control models for exchanges and ownership issues, etc. This is based mostly on work from Freek Dijkstra, Leon Gommans. Please see this presentation I gave in Salt Lake City at I2Techs: "What makes an Exchange open?" http://staff.science.uva.nl/~delaat/talks/cdl-2005-02-13.pdf and gridnets: "Optical/Photonic exchanges" http://staff.science.uva.nl/~delaat/talks/cdl-2004-10-29.pdf Freek Dijkstra's thesis: http://staff.science.uva.nl/~delaat/pubs/2010-t-1.pdf And this paper: [2004-c-3] Freek Dijkstra, Cees de Laat, "Optical Exchanges", GRIDNETS conference proceedings, oct 2004, http://staff.science.uva.nl/~delaat/pubs/2004-c-3.pdf ========================= Best regards, Cees. On Feb 22, 2010, at 12:00 PM, Guy Roberts wrote:
Jeroen,
If we put aside the question of point vs port naming for the moment, I think that John's slides raise an important question. This is how best to describe connectivity between networks.
One option is to carry over the exiting NML concepts and assign a link as the connection between two networks. In this case the link will have to be 'un-owned' i.e. it is not within the control or ownership of either network.
The alternative option presented by John is to use a port or point concept to joint two ports on adjacent networks. In this case there are no objects (i.e links) between networks - this solves the problem of un-owned resources.
To understand the implications of the existing NML model better, lets take the example of a fibre that connects two Ethernet switches in adjacent racks. In this case I expect that the NML model will nominate the two Ethernet ports on the switches as 'Ports' and the fibre as a 'Link'. In this example it might be possible to replace the fibre with a transatlantic wavelength leased by one of the end networks. The question in my mind is how we allocate ownership of the inter-domain 'link'.
If we follow John's model and insist that there are no resources that are 'un-owned', then we need to allow the modelling of connectors that do not belong to switches. So going back to my previous example, the demarcation point between networks moves from the Ethernet ports on the switches to a connector on a distribution frame that marks the boundary of physical ownership between the two networks. In other words the schema would model the demarcation point between networks in a much more literal physical way.
The question in my mind is whether there is a real use-case for the second model. Does NSI need to model the demarcation of ownership of items in the inter-network space, eg wavelengths or patch chords between providers? This is a interesting question and needs a very clearly documented use-case.
Guy
-----Original Message----- From: Jeroen van der Ham [mailto:vdham@uva.nl] Sent: 21 February 2010 21:08 To: John Vollbrecht Cc: NSI WG Subject: Re: [Nsi-wg] NML topology
On 21/02/2010 18:20, John Vollbrecht wrote:
Attached is set of ppt slides to describe interdomain topology. I hope this helps - it is based on conversations in the NML group, and is my understanding of what the Glossary of terms that Guy is reviewing (and I think will review next Wed).
I just want to clarify my view of the conversation we have had in the NML group about this issue. This was mainly a discussion between myself and John wherein I tried to understand the NSI issue of describing inter-domain topologies.
The current NML topology model does not have "Points". Nor do we currently have plans to add them. *Unless* there is a use-case showing the need of Points, which clearly outlines why it is not possible to describe domain boundaries with the current NML Topology model. So far, I have not seen such a clear and valid use-case for "Points".
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
Can I summarize this discussion as follows? Requirement: It should be possible to assign a policy to an (interdomain) link. Of course, I can think of a solution (e.g. make that link part of a topology, like John's second picture, assign the topology to a networkdomain, and assign a policy to that networkdomain). However, this seems out of scope. I think the best way forward is to describe this and other requirements and forward them to the NML and ask the NML folks to come up with a solution for the requirement. I also wholeheartedly invite all NSI group members to become a "NML folk" too by joining the NML list! Regards, Freek
Hello all, I my opinion one of the main problems that has held up progress in the NSI working group has been our failure to agree on a clear set of NSI requirements for network modelling. I think we have agreed that these should be a minimal set of extensions to the existing NML model, so this should not be a very large set of requirements. What has happen is that many alternative proposals for network models have been suggested, without first clearly identifying and agreeing a set of requirements. I think this has been back-to-front, first we should identify the requirements, and then a group of modelling experts should come up with a proposal for NML extensions. So with this new approach in mind, I would like to kick of a discussion on what the essential requirements NSI has for network modelling. These should only include requirements that go beyond the functions that are already supported in the current NML definition. I suggest the following 10 requirements as a starter: Requirement 1: The model should be able to describe a grouping of network resources that are owned and controlled by a single provider or NSA. (I will call this a NETWORK for the moment) Requirement 2: The model should be able to describe a grouping of NETWORKs. (e.g. a federation of providers with shared policy) Requirement 3: The model should be able to describe resources (ports/points) in a NETWORK that are available for connecting to other NETWORKs. (I will call this a network connection point NCP for the moment) Requirement 4: These NPs should be able to be performed at the end of a link that is internal to the domain as well as to ports on a device. (in my opinion the NCP on a link requirement needs a use-case) Requirement 5: The model should be able to describe an arbitrary number of layers of logical ports within a NCP. Requirement 6: The model should be able to describe connectivity between NETWORKs. (I will call this inter network connection (INCs) for the moment) Requirement 7: The model should be able to describe groups of INCs. Requirement 8: The resources that make up INCs should have ownership by a clearly identifiable provider. (i.e. resources without NSA ownership are not allowed). (note: Does this also include the patch cord between providers?) Requirement 9: The model should allow policy to be assigned to INCs, even where the INC is wholly or partly made up of passive resources. Requirement 10: The model should be able to fully describe a circuit (i.e. NSI service) that transits the topology. Any thoughts on these and other requirements would be helpful. Guy -----Original Message----- From: Freek Dijkstra [mailto:Freek.Dijkstra@sara.nl] Sent: 22 February 2010 13:52 To: NSI WG Cc: Guy Roberts; Jeroen van der Ham; John Vollbrecht Subject: Re: [Nsi-wg] NML topology Can I summarize this discussion as follows? Requirement: It should be possible to assign a policy to an (interdomain) link. Of course, I can think of a solution (e.g. make that link part of a topology, like John's second picture, assign the topology to a networkdomain, and assign a policy to that networkdomain). However, this seems out of scope. I think the best way forward is to describe this and other requirements and forward them to the NML and ask the NML folks to come up with a solution for the requirement. I also wholeheartedly invite all NSI group members to become a "NML folk" too by joining the NML list! Regards, Freek
Hi Guy, Thanks a lot! With a list like this we can take it to the NML and see how this applies to our current ideas. I highly encourage your distinction between requirement and solution. Two questions (more will pop up later):
Requirement 1: The model should be able to describe a grouping of network resources that are owned and controlled by a single provider or NSA. (I will call this a NETWORK for the moment) Requirement 2: The model should be able to describe a grouping of NETWORKs. (e.g. a federation of providers with shared policy)
I understand the word "controlled". What do you mean with "owned"? The entity that decides on the policy? Is that always the same as the controller, or is there a 1:many, many:1 or many:many relation between "owner" and "controller", or is there no requirement for this.
Requirement 10: The model should be able to fully describe a circuit (i.e. NSI service) that transits the topology.
Does this mean we only need to describe the full circuit with all details (all device and links along the way), or is it also required to describe a circuit without details (either just the end nodes, the loose hops, the internetwork links, ...). Also a general question: Is a NSI circuit single layer, or is it also required to specify different layers? (Perhaps this last is more a question for NML). Regards, Freek
Freek, Some interesting questions, here are my thoughts your questions- Requirement 1: In my opinion each network resource should be owned by only one NSA. However, one NSA can own many resources. I guess this means that 'owned' and 'controlled' are synonymous. Though perhaps the distinction could be that a passive object (eg patchcord link) can only be owned and not managed? Requirement 10: We need to be clear about the difference between a 'Path' and 'Connection'. According to NSI terminology (the current NSI terminology will be presented on the Wednesday call) a Connection is the conduit that transfers bits. A 'Path' is the output of the path computation and is a directed list of routing objects (say ports), this may be a complete list or a minimum list which only includes end ports. It is possible that a 'Path' could include routing objects like intermediate networks. So in my mind, a Path should be made up of existing NML resources, such as ports, links etc. At this stage, I don't know that any new network definitions are necessary to describe a Path. Guy -----Original Message----- From: Freek Dijkstra [mailto:Freek.Dijkstra@sara.nl] Sent: 22 February 2010 16:34 To: Guy Roberts Cc: NSI WG; Jeroen van der Ham; John Vollbrecht Subject: Re: [Nsi-wg] NML topology Hi Guy, Thanks a lot! With a list like this we can take it to the NML and see how this applies to our current ideas. I highly encourage your distinction between requirement and solution. Two questions (more will pop up later):
Requirement 1: The model should be able to describe a grouping of network resources that are owned and controlled by a single provider or NSA. (I will call this a NETWORK for the moment) Requirement 2: The model should be able to describe a grouping of NETWORKs. (e.g. a federation of providers with shared policy)
I understand the word "controlled". What do you mean with "owned"? The entity that decides on the policy? Is that always the same as the controller, or is there a 1:many, many:1 or many:many relation between "owner" and "controller", or is there no requirement for this.
Requirement 10: The model should be able to fully describe a circuit (i.e. NSI service) that transits the topology.
Does this mean we only need to describe the full circuit with all details (all device and links along the way), or is it also required to describe a circuit without details (either just the end nodes, the loose hops, the internetwork links, ...). Also a general question: Is a NSI circuit single layer, or is it also required to specify different layers? (Perhaps this last is more a question for NML). Regards, Freek
Comments in line: Guy Roberts wrote:
Freek,
Some interesting questions, here are my thoughts your questions-
Requirement 1: In my opinion each network resource should be owned by only one NSA. However, one NSA can own many resources. I guess this means that 'owned' and 'controlled' are synonymous. Though perhaps the distinction could be that a passive object (eg patchcord link) can only be owned and not managed?
It seems to me even a passive patch cable is still managed - what happens if it breaks? I think the issue here is that it is a component of a network, and b/y definition/ it is managed by the associated NSA. (What that NSA needs to do - if anythng- to control or manage the patch cable is a separate issue. ) Also, often in this whole conflagration we find that one agent controls the port on one end of a link and another agent controls the port on the other end, and these two separate objects must *MUST* correspond to one another, ..so the configuration is negotiated via protocols and the link in-between simply reflects this agreed config. It is sort of moot who actually owns the resource, or "controls" it, as that agent simply has the priviledge of writing the negotiated configuration into the device... I think owned and controlled are synonymous for our purposes - even if the physical device interface is delegated to a subordinate function (e.g. an RM) it is still under the control and management of the NSA. Jerry
I think owned and controlled are synonymous for our purposes - even if the physical device interface is delegated to a subordinate function (e.g. an RM) it is still under the control and management of the NSA.
I agree with your comments. Let me try to re-iterate the conclusions, so it can be captured in the Architecture Document: - There can be only one owner of the resource that controls/manages/provisions the resource. This is known as the Resource Manager. - All others can only "request" access (provision, schedule, reserve) to that resource from that resource manager (RM) - The service "request" interface is "Network Service Interface" (NSI). - NSI + RM = NSA. This does not mean they have to be the same software module or function. The two functions can be distributed, but for the outside world looking in, NSA includes the RM capability. - ONE NSA can manage MULTIPLE local RM's. The interface between NSA and RM MUST NOT be a publicly accessible interface. An RM can ONLY be controlled by a SINGLE NSA. - An NSA can decompose the service request to multiple sub-requests and send them to other NSAs. An NSA that decomposes the requests, MUST compose the responses and respond to the original service request. Inder On Feb 23, 2010, at 5:46 AM, Jerry Sobieski wrote:
Comments in line:
Guy Roberts wrote:
Freek,
Some interesting questions, here are my thoughts your questions-
Requirement 1: In my opinion each network resource should be owned by only one NSA. However, one NSA can own many resources. I guess this means that 'owned' and 'controlled' are synonymous. Though perhaps the distinction could be that a passive object (eg patchcord link) can only be owned and not managed?
It seems to me even a passive patch cable is still managed - what happens if it breaks? I think the issue here is that it is a component of a network, and by definition it is managed by the associated NSA. (What that NSA needs to do - if anythng- to control or manage the patch cable is a separate issue. ) Also, often in this whole conflagration we find that one agent controls the port on one end of a link and another agent controls the port on the other end, and these two separate objects must *MUST* correspond to one another, ..so the configuration is negotiated via protocols and the link in-between simply reflects this agreed config. It is sort of moot who actually owns the resource, or "controls" it, as that agent simply has the priviledge of writing the negotiated configuration into the device...
I think owned and controlled are synonymous for our purposes - even if the physical device interface is delegated to a subordinate function (e.g. an RM) it is still under the control and management of the NSA.
Jerry _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Inder and All, I also agree with all the below statements, with the exception that an "NSA must include RM capabilities". I can imagine an NSA that serves to process and break up a single request from a requester agent and then use the NSI to make sub-requests to other NSAs that do have RM capability. In this example the first NSA does not have resources that it directly manages and it also does not manage other NSAs. In this way an NSA can be a neutral entity (broker) that is not associated with network resources. Thanks, Gigi Inder Monga wrote:
I think owned and controlled are synonymous for our purposes - even if the physical device interface is delegated to a subordinate function (e.g. an RM) it is still under the control and management of the NSA.
I agree with your comments.
Let me try to re-iterate the conclusions, so it can be captured in the Architecture Document:
- There can be only one owner of the resource that controls/manages/provisions the resource. This is known as the Resource Manager.
- All others can only "request" access (provision, schedule, reserve) to that resource from that resource manager (RM)
- The service "request" interface is "Network Service Interface" (NSI).
- NSI + RM = NSA. This does not mean they have to be the same software module or function. The two functions can be distributed, but for the outside world looking in, NSA includes the RM capability.
- ONE NSA can manage MULTIPLE local RM's. The interface between NSA and RM MUST NOT be a publicly accessible interface. An RM can ONLY be controlled by a SINGLE NSA.
- An NSA can decompose the service request to multiple sub-requests and send them to other NSAs. An NSA that decomposes the requests, MUST compose the responses and respond to the original service request.
Inder
On Feb 23, 2010, at 5:46 AM, Jerry Sobieski wrote:
Comments in line:
Guy Roberts wrote:
Freek,
Some interesting questions, here are my thoughts your questions-
Requirement 1: In my opinion each network resource should be owned by only one NSA. However, one NSA can own many resources. I guess this means that 'owned' and 'controlled' are synonymous. Though perhaps the distinction could be that a passive object (eg patchcord link) can only be owned and not managed?
It seems to me even a passive patch cable is still managed - what happens if it breaks? I think the issue here is that it is a component of a network, and b/y definition/ it is managed by the associated NSA. (What that NSA needs to do - if anythng- to control or manage the patch cable is a separate issue. ) Also, often in this whole conflagration we find that one agent controls the port on one end of a link and another agent controls the port on the other end, and these two separate objects must *MUST* correspond to one another, ..so the configuration is negotiated via protocols and the link in-between simply reflects this agreed config. It is sort of moot who actually owns the resource, or "controls" it, as that agent simply has the priviledge of writing the negotiated configuration into the device...
I think owned and controlled are synonymous for our purposes - even if the physical device interface is delegated to a subordinate function (e.g. an RM) it is still under the control and management of the NSA.
Jerry _______________________________________________ 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 http://www.ogf.org/mailman/listinfo/nsi-wg
OK Gigi, I think you make a good point regarding the broker function of an NSA. Let me try to rephrase some of the statements:
- NSI + RM = NSA. This does not mean they have to be the same software module or function. The two functions can be distributed, but for the outside world looking in, NSA includes the RM capability.
- NSA MAY include RM capability. NSI + Service Request Composition/Decomposition + {RM} (optional) = NSA.
- ONE NSA can manage MULTIPLE local RM's. The interface between NSA and RM MUST NOT be a publicly accessible interface. An RM can ONLY be controlled by a SINGLE NSA.
- ONE NSA can manage ZERO TO MULTIPLE local RM's. The interface between NSA and RM MUST NOT be a publicly accessible interface. An RM can ONLY be controlled by a SINGLE NSA. On Feb 23, 2010, at 9:00 AM, Gigi Karmous-Edwards wrote:
Inder and All,
I also agree with all the below statements, with the exception that an "NSA must include RM capabilities". I can imagine an NSA that serves to process and break up a single request from a requester agent and then use the NSI to make sub-requests to other NSAs that do have RM capability. In this example the first NSA does not have resources that it directly manages and it also does not manage other NSAs.
In this way an NSA can be a neutral entity (broker) that is not associated with network resources.
Thanks, Gigi
Inder Monga wrote:
I think owned and controlled are synonymous for our purposes - even if the physical device interface is delegated to a subordinate function (e.g. an RM) it is still under the control and management of the NSA.
I agree with your comments.
Let me try to re-iterate the conclusions, so it can be captured in the Architecture Document:
- There can be only one owner of the resource that controls/manages/provisions the resource. This is known as the Resource Manager.
- All others can only "request" access (provision, schedule, reserve) to that resource from that resource manager (RM)
- The service "request" interface is "Network Service Interface" (NSI).
- NSI + RM = NSA. This does not mean they have to be the same software module or function. The two functions can be distributed, but for the outside world looking in, NSA includes the RM capability.
- ONE NSA can manage MULTIPLE local RM's. The interface between NSA and RM MUST NOT be a publicly accessible interface. An RM can ONLY be controlled by a SINGLE NSA.
- An NSA can decompose the service request to multiple sub-requests and send them to other NSAs. An NSA that decomposes the requests, MUST compose the responses and respond to the original service request.
Inder
On Feb 23, 2010, at 5:46 AM, Jerry Sobieski wrote:
Comments in line:
Guy Roberts wrote:
Freek,
Some interesting questions, here are my thoughts your questions-
Requirement 1: In my opinion each network resource should be owned by only one NSA. However, one NSA can own many resources. I guess this means that 'owned' and 'controlled' are synonymous. Though perhaps the distinction could be that a passive object (eg patchcord link) can only be owned and not managed?
It seems to me even a passive patch cable is still managed - what happens if it breaks? I think the issue here is that it is a component of a network, and by definition it is managed by the associated NSA. (What that NSA needs to do - if anythng- to control or manage the patch cable is a separate issue. ) Also, often in this whole conflagration we find that one agent controls the port on one end of a link and another agent controls the port on the other end, and these two separate objects must *MUST* correspond to one another, ..so the configuration is negotiated via protocols and the link in-between simply reflects this agreed config. It is sort of moot who actually owns the resource, or "controls" it, as that agent simply has the priviledge of writing the negotiated configuration into the device...
I think owned and controlled are synonymous for our purposes - even if the physical device interface is delegated to a subordinate function (e.g. an RM) it is still under the control and management of the NSA.
Jerry _______________________________________________ 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
Agreed, good point Gigi. Hierarchical NSA deployments *require* this to be true, since the distribution of entities in the service plane does not map to the one in the transport plane is this case. I'm catching up the discussion, regards, -- Joan A. García-Espín CTX, i2CAT Foundation El 23/02/2010, a las 18:07, Inder Monga escribió:
OK Gigi, I think you make a good point regarding the broker function of an NSA. Let me try to rephrase some of the statements:
- NSI + RM = NSA. This does not mean they have to be the same software module or function. The two functions can be distributed, but for the outside world looking in, NSA includes the RM capability.
- NSA MAY include RM capability. NSI + Service Request Composition/ Decomposition + {RM} (optional) = NSA.
- ONE NSA can manage MULTIPLE local RM's. The interface between NSA and RM MUST NOT be a publicly accessible interface. An RM can ONLY be controlled by a SINGLE NSA.
- ONE NSA can manage ZERO TO MULTIPLE local RM's. The interface between NSA and RM MUST NOT be a publicly accessible interface. An RM can ONLY be controlled by a SINGLE NSA.
On Feb 23, 2010, at 9:00 AM, Gigi Karmous-Edwards wrote:
Inder and All,
I also agree with all the below statements, with the exception that an "NSA must include RM capabilities". I can imagine an NSA that serves to process and break up a single request from a requester agent and then use the NSI to make sub-requests to other NSAs that do have RM capability. In this example the first NSA does not have resources that it directly manages and it also does not manage other NSAs.
In this way an NSA can be a neutral entity (broker) that is not associated with network resources.
Thanks, Gigi
Inder Monga wrote:
I think owned and controlled are synonymous for our purposes - even if the physical device interface is delegated to a subordinate function (e.g. an RM) it is still under the control and management of the NSA.
I agree with your comments.
Let me try to re-iterate the conclusions, so it can be captured in the Architecture Document:
- There can be only one owner of the resource that controls/ manages/provisions the resource. This is known as the Resource Manager.
- All others can only "request" access (provision, schedule, reserve) to that resource from that resource manager (RM)
- The service "request" interface is "Network Service Interface" (NSI).
- NSI + RM = NSA. This does not mean they have to be the same software module or function. The two functions can be distributed, but for the outside world looking in, NSA includes the RM capability.
- ONE NSA can manage MULTIPLE local RM's. The interface between NSA and RM MUST NOT be a publicly accessible interface. An RM can ONLY be controlled by a SINGLE NSA.
- An NSA can decompose the service request to multiple sub- requests and send them to other NSAs. An NSA that decomposes the requests, MUST compose the responses and respond to the original service request.
Inder
On Feb 23, 2010, at 5:46 AM, Jerry Sobieski wrote:
Comments in line:
Guy Roberts wrote:
Freek,
Some interesting questions, here are my thoughts your questions-
Requirement 1: In my opinion each network resource should be owned by only one NSA. However, one NSA can own many resources. I guess this means that 'owned' and 'controlled' are synonymous. Though perhaps the distinction could be that a passive object (eg patchcord link) can only be owned and not managed?
It seems to me even a passive patch cable is still managed - what happens if it breaks? I think the issue here is that it is a component of a network, and by definition it is managed by the associated NSA. (What that NSA needs to do - if anythng- to control or manage the patch cable is a separate issue. ) Also, often in this whole conflagration we find that one agent controls the port on one end of a link and another agent controls the port on the other end, and these two separate objects must *MUST* correspond to one another, ..so the configuration is negotiated via protocols and the link in-between simply reflects this agreed config. It is sort of moot who actually owns the resource, or "controls" it, as that agent simply has the priviledge of writing the negotiated configuration into the device...
I think owned and controlled are synonymous for our purposes - even if the physical device interface is delegated to a subordinate function (e.g. an RM) it is still under the control and management of the NSA.
Jerry _______________________________________________ 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
Wonderful! Consensus...ahhh:-) This is good Inder and Gigi. (quite out of character- I have nothing to add:-) Jerry Gigi Karmous-Edwards wrote:
Inder and All,
I also agree with all the below statements, with the exception that an "NSA must include RM capabilities". I can imagine an NSA that serves to process and break up a single request from a requester agent and then use the NSI to make sub-requests to other NSAs that do have RM capability. In this example the first NSA does not have resources that it directly manages and it also does not manage other NSAs.
In this way an NSA can be a neutral entity (broker) that is not associated with network resources.
Thanks, Gigi
Inder Monga wrote:
I think owned and controlled are synonymous for our purposes - even if the physical device interface is delegated to a subordinate function (e.g. an RM) it is still under the control and management of the NSA.
I agree with your comments.
Let me try to re-iterate the conclusions, so it can be captured in the Architecture Document:
- There can be only one owner of the resource that controls/manages/provisions the resource. This is known as the Resource Manager.
- All others can only "request" access (provision, schedule, reserve) to that resource from that resource manager (RM)
- The service "request" interface is "Network Service Interface" (NSI).
- NSI + RM = NSA. This does not mean they have to be the same software module or function. The two functions can be distributed, but for the outside world looking in, NSA includes the RM capability.
- ONE NSA can manage MULTIPLE local RM's. The interface between NSA and RM MUST NOT be a publicly accessible interface. An RM can ONLY be controlled by a SINGLE NSA.
- An NSA can decompose the service request to multiple sub-requests and send them to other NSAs. An NSA that decomposes the requests, MUST compose the responses and respond to the original service request.
Inder
On Feb 23, 2010, at 5:46 AM, Jerry Sobieski wrote:
Comments in line:
Guy Roberts wrote:
Freek,
Some interesting questions, here are my thoughts your questions-
Requirement 1: In my opinion each network resource should be owned by only one NSA. However, one NSA can own many resources. I guess this means that 'owned' and 'controlled' are synonymous. Though perhaps the distinction could be that a passive object (eg patchcord link) can only be owned and not managed?
It seems to me even a passive patch cable is still managed - what happens if it breaks? I think the issue here is that it is a component of a network, and b/y definition/ it is managed by the associated NSA. (What that NSA needs to do - if anythng- to control or manage the patch cable is a separate issue. ) Also, often in this whole conflagration we find that one agent controls the port on one end of a link and another agent controls the port on the other end, and these two separate objects must *MUST* correspond to one another, ..so the configuration is negotiated via protocols and the link in-between simply reflects this agreed config. It is sort of moot who actually owns the resource, or "controls" it, as that agent simply has the priviledge of writing the negotiated configuration into the device...
I think owned and controlled are synonymous for our purposes - even if the physical device interface is delegated to a subordinate function (e.g. an RM) it is still under the control and management of the NSA.
Jerry _______________________________________________ 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
On 23/02/2010 17:37, Inder Monga wrote:
- ONE NSA can manage MULTIPLE local RM's. The interface between NSA and RM MUST NOT be a publicly accessible interface. An RM can ONLY be controlled by a SINGLE NSA.
Why must the interface not be publicly accessible? Didn't we agree that this interface is outside the scope of the NSI, and therefore we can not say anything about this? Jeroen.
Good idea Guy...I have a couple of posts...here is the first:. I suggest we focus on which NSI service request parameters or semantics have topological significance and what those are. For instance: *1. NSI: A Connection request must, at a minimum, specify the ingress point and the egress point. The Connection request may also specify intermediate transit points for the connection. The semantics of loose hop request is PO={A,B,C}, is equivalent to Connection A>B concatenated with Connection B>C. * Topo Requirement: Each of these "point" identifiers must uniquely determine and map to a location in the transport topology. What is the NSI definition of a "point"used in this context? It seems to correspond to our STP discussion...so we need to decide what a point in the Path Object really refers to topologically. *2. NSI: A Provider NSA is responsible for decomposing the Connection request (into piecewise segments defined by the PO) and forwarding sub-requests to other service agents** as it deems appropriate or necessary**, and insuring the returned sub-segments can be assembled into a single fully satisfied Connection and returning that Connection result to the Requesting NSA. * Requirement: Define how the NSA handles Connection requests. a) The NSA decomposes the request into a set of sub-segments as defined by the PO. b) The NSA must forward each sub-request to/towards the NSA that owns the ingress STP of the sub-request, /[Here is where topology comes into play - how do we know where to send a request? Must map STP to NSA owner or have reachability in the topology..] / c) If an NSA receives a request whose ingress STP is in the local Domain, the NSA invokes the PathFinder to reserve a Path towards the next STP [/NSA must be able to recognize STPs in its local domain/] d) Upon successful reservation, the returned POs of the sub-requests are merged into a single PO and returned to the originating Requester. *3. NSI: Upon successfull reservation, a Path Object is returned to the user describing the resulting Path. This PO will contain the STPs stipulated by the originating request, and will contain either a) STPs of the as-built Connection, or b) named Path Object(s) for opaque as-built information.* Requirement: Path Object definition. Including opaque Named POs that are only revealed to authorized requesters. A PO must contain STPs, but must also include a Named PO - which must carry some authorization policy. How do these Named POs get resolved? what do they look like, how are names constructed, etc. The above notion that we forward requests from one NSA to another based upon some ownership means we must define that ownership concept. Therein lies the notions of grouping resources into Networks, and a single NSA King for each Network kingdom :-) If STPs are part of that group, what are they and how do we summarize such info? However, we do not have a trust relationship with all NSAs - its scaling problem. We must assume that we will connect directly with some neighbor Networks, and have a trusted relationship with them. But we will not (cannot) directly connect to every network, and therefore some such "far-away" networks will not recognize and trust our local NSA. For these latter cases, the only way we will know of that far-away domain is if one of our direct neighbors offers to act as transit to to Far-Away domain by announcing all or some of Far-Away's topology. In this case, we see far-away, but we must rely on our neighbor to forward any requests to Far-Away. If our NSA encounters an STP that lives in Far-Away, and our peering table has no trust with Far-Away, then we must send our request to our neighbor who acts as intermediary. (In point of fact, our neighbor acts no differently than it would for any other request - it sees the Far-Away STP and forwards the request likewise.) This may generate another topology requirement- that of reachability. I.e. how do we describe the set of points (STPs) reachable within (or through) a given domain? We have to recognize that our reachable end systems or STPs will almost immediately be counted in the thousands. We probably need some sort of hierarchichal naming scheme. thoughts? Jerry Guy Roberts wrote:
I suggest the following 10 requirements as a starter:
Requirement 1: The model should be able to describe a grouping of network resources that are owned and controlled by a single provider or NSA. (I will call this a NETWORK for the moment)
Requirement 2: The model should be able to describe a grouping of NETWORKs. (e.g. a federation of providers with shared policy) Requirement 3: The model should be able to describe resources (ports/points) in a NETWORK that are available for connecting to other NETWORKs. (I will call this a network connection point NCP for the moment) Requirement 4: These NPs should be able to be performed at the end of a link that is internal to the domain as well as to ports on a device. (in my opinion the NCP on a link requirement needs a use-case) Requirement 5: The model should be able to describe an arbitrary number of layers of logical ports within a NCP. Requirement 6: The model should be able to describe connectivity between NETWORKs. (I will call this inter network connection (INCs) for the moment) Requirement 7: The model should be able to describe groups of INCs. Requirement 8: The resources that make up INCs should have ownership by a clearly identifiable provider. (i.e. resources without NSA ownership are not allowed). (note: Does this also include the patch cord between providers?) Requirement 9: The model should allow policy to be assigned to INCs, even where the INC is wholly or partly made up of passive resources. Requirement 10: The model should be able to fully describe a circuit (i.e. NSI service) that transits the topology.
Any thoughts on these and other requirements would be helpful.
Guy
-----Original Message----- From: Freek Dijkstra [mailto:Freek.Dijkstra@sara.nl] Sent: 22 February 2010 13:52 To: NSI WG Cc: Guy Roberts; Jeroen van der Ham; John Vollbrecht Subject: Re: [Nsi-wg] NML topology
Can I summarize this discussion as follows?
Requirement: It should be possible to assign a policy to an (interdomain) link.
Of course, I can think of a solution (e.g. make that link part of a topology, like John's second picture, assign the topology to a networkdomain, and assign a policy to that networkdomain). However, this seems out of scope. I think the best way forward is to describe this and other requirements and forward them to the NML and ask the NML folks to come up with a solution for the requirement. I also wholeheartedly invite all NSI group members to become a "NML folk" too by joining the NML list!
Regards, Freek _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Jerry, I like what you have done here - the point is to first state clearly what the NSI 'Connection Service' needs to do, and then to derive the topology requirements from these service functions. Will you be able to make tomorrow's call? I would like to make this make this a topic for discussion. Guy From: Jerry Sobieski [mailto:jerry@nordu.net] Sent: 23 February 2010 04:46 To: Guy Roberts Cc: Freek Dijkstra; NSI WG Subject: Re: [Nsi-wg] NML topology Good idea Guy...I have a couple of posts...here is the first:. I suggest we focus on which NSI service request parameters or semantics have topological significance and what those are. For instance: 1. NSI: A Connection request must, at a minimum, specify the ingress point and the egress point. The Connection request may also specify intermediate transit points for the connection. The semantics of loose hop request is PO={A,B,C}, is equivalent to Connection A>B concatenated with Connection B>C. Topo Requirement: Each of these "point" identifiers must uniquely determine and map to a location in the transport topology. What is the NSI definition of a "point"used in this context? It seems to correspond to our STP discussion...so we need to decide what a point in the Path Object really refers to topologically. 2. NSI: A Provider NSA is responsible for decomposing the Connection request (into piecewise segments defined by the PO) and forwarding sub-requests to other service agents as it deems appropriate or necessary, and insuring the returned sub-segments can be assembled into a single fully satisfied Connection and returning that Connection result to the Requesting NSA. Requirement: Define how the NSA handles Connection requests. a) The NSA decomposes the request into a set of sub-segments as defined by the PO. b) The NSA must forward each sub-request to/towards the NSA that owns the ingress STP of the sub-request, [Here is where topology comes into play - how do we know where to send a request? Must map STP to NSA owner or have reachability in the topology..] c) If an NSA receives a request whose ingress STP is in the local Domain, the NSA invokes the PathFinder to reserve a Path towards the next STP [NSA must be able to recognize STPs in its local domain] d) Upon successful reservation, the returned POs of the sub-requests are merged into a single PO and returned to the originating Requester. 3. NSI: Upon successfull reservation, a Path Object is returned to the user describing the resulting Path. This PO will contain the STPs stipulated by the originating request, and will contain either a) STPs of the as-built Connection, or b) named Path Object(s) for opaque as-built information. Requirement: Path Object definition. Including opaque Named POs that are only revealed to authorized requesters. A PO must contain STPs, but must also include a Named PO - which must carry some authorization policy. How do these Named POs get resolved? what do they look like, how are names constructed, etc. The above notion that we forward requests from one NSA to another based upon some ownership means we must define that ownership concept. Therein lies the notions of grouping resources into Networks, and a single NSA King for each Network kingdom :-) If STPs are part of that group, what are they and how do we summarize such info? However, we do not have a trust relationship with all NSAs - its scaling problem. We must assume that we will connect directly with some neighbor Networks, and have a trusted relationship with them. But we will not (cannot) directly connect to every network, and therefore some such "far-away" networks will not recognize and trust our local NSA. For these latter cases, the only way we will know of that far-away domain is if one of our direct neighbors offers to act as transit to to Far-Away domain by announcing all or some of Far-Away's topology. In this case, we see far-away, but we must rely on our neighbor to forward any requests to Far-Away. If our NSA encounters an STP that lives in Far-Away, and our peering table has no trust with Far-Away, then we must send our request to our neighbor who acts as intermediary. (In point of fact, our neighbor acts no differently than it would for any other request - it sees the Far-Away STP and forwards the request likewise.) This may generate another topology requirement- that of reachability. I.e. how do we describe the set of points (STPs) reachable within (or through) a given domain? We have to recognize that our reachable end systems or STPs will almost immediately be counted in the thousands. We probably need some sort of hierarchichal naming scheme. thoughts? Jerry Guy Roberts wrote: I suggest the following 10 requirements as a starter: Requirement 1: The model should be able to describe a grouping of network resources that are owned and controlled by a single provider or NSA. (I will call this a NETWORK for the moment) Requirement 2: The model should be able to describe a grouping of NETWORKs. (e.g. a federation of providers with shared policy) Requirement 3: The model should be able to describe resources (ports/points) in a NETWORK that are available for connecting to other NETWORKs. (I will call this a network connection point NCP for the moment) Requirement 4: These NPs should be able to be performed at the end of a link that is internal to the domain as well as to ports on a device. (in my opinion the NCP on a link requirement needs a use-case) Requirement 5: The model should be able to describe an arbitrary number of layers of logical ports within a NCP. Requirement 6: The model should be able to describe connectivity between NETWORKs. (I will call this inter network connection (INCs) for the moment) Requirement 7: The model should be able to describe groups of INCs. Requirement 8: The resources that make up INCs should have ownership by a clearly identifiable provider. (i.e. resources without NSA ownership are not allowed). (note: Does this also include the patch cord between providers?) Requirement 9: The model should allow policy to be assigned to INCs, even where the INC is wholly or partly made up of passive resources. Requirement 10: The model should be able to fully describe a circuit (i.e. NSI service) that transits the topology. Any thoughts on these and other requirements would be helpful. Guy -----Original Message----- From: Freek Dijkstra [mailto:Freek.Dijkstra@sara.nl] Sent: 22 February 2010 13:52 To: NSI WG Cc: Guy Roberts; Jeroen van der Ham; John Vollbrecht Subject: Re: [Nsi-wg] NML topology Can I summarize this discussion as follows? Requirement: It should be possible to assign a policy to an (interdomain) link. Of course, I can think of a solution (e.g. make that link part of a topology, like John's second picture, assign the topology to a networkdomain, and assign a policy to that networkdomain). However, this seems out of scope. I think the best way forward is to describe this and other requirements and forward them to the NML and ask the NML folks to come up with a solution for the requirement. I also wholeheartedly invite all NSI group members to become a "NML folk" too by joining the NML list! Regards, Freek _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org<mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
Yup - I will be there - wouldn't miss it for the world:-) J Guy Roberts wrote:
Jerry,
I like what you have done here -- the point is to first state clearly what the NSI 'Connection Service' needs to do, and then to derive the topology requirements from these service functions.
Will you be able to make tomorrow's call? I would like to make this make this a topic for discussion.
Guy
*From:* Jerry Sobieski [mailto:jerry@nordu.net] *Sent:* 23 February 2010 04:46 *To:* Guy Roberts *Cc:* Freek Dijkstra; NSI WG *Subject:* Re: [Nsi-wg] NML topology
Good idea Guy...I have a couple of posts...here is the first:.
I suggest we focus on which NSI service request parameters or semantics have topological significance and what those are. For instance:
*1. NSI: A Connection request must, at a minimum, specify the ingress point and the egress point. The Connection request may also specify intermediate transit points for the connection. The semantics of loose hop request is PO={A,B,C}, is equivalent to Connection A>B concatenated with Connection B>C. *
Topo Requirement: Each of these "point" identifiers must uniquely determine and map to a location in the transport topology. What is the NSI definition of a "point"used in this context? It seems to correspond to our STP discussion...so we need to decide what a point in the Path Object really refers to topologically.
*2. NSI: A Provider NSA is responsible for decomposing the Connection request (into piecewise segments defined by the PO) and forwarding sub-requests to other service agents as it deems appropriate or necessary, and insuring the returned sub-segments can be assembled into a single fully satisfied Connection and returning that Connection result to the Requesting NSA. *
Requirement: Define how the NSA handles Connection requests. a) The NSA decomposes the request into a set of sub-segments as defined by the PO. b) The NSA must forward each sub-request to/towards the NSA that owns the ingress STP of the sub-request, /[Here is where topology comes into play - how do we know where to send a request? Must map STP to NSA owner or have reachability in the topology..] / c) If an NSA receives a request whose ingress STP is in the local Domain, the NSA invokes the PathFinder to reserve a Path towards the next STP [/NSA must be able to recognize STPs in its local domain/] d) Upon successful reservation, the returned POs of the sub-requests are merged into a single PO and returned to the originating Requester.
*3. NSI: Upon successfull reservation, a Path Object is returned to the user describing the resulting Path. This PO will contain the STPs stipulated by the originating request, and will contain either a) STPs of the as-built Connection, or b) named Path Object(s) for opaque as-built information.*
Requirement: Path Object definition. Including opaque Named POs that are only revealed to authorized requesters. A PO must contain STPs, but must also include a Named PO - which must carry some authorization policy. How do these Named POs get resolved? what do they look like, how are names constructed, etc.
The above notion that we forward requests from one NSA to another based upon some ownership means we must define that ownership concept. Therein lies the notions of grouping resources into Networks, and a single NSA King for each Network kingdom :-) If STPs are part of that group, what are they and how do we summarize such info?
However, we do not have a trust relationship with all NSAs - its scaling problem. We must assume that we will connect directly with some neighbor Networks, and have a trusted relationship with them. But we will not (cannot) directly connect to every network, and therefore some such "far-away" networks will not recognize and trust our local NSA. For these latter cases, the only way we will know of that far-away domain is if one of our direct neighbors offers to act as transit to to Far-Away domain by announcing all or some of Far-Away's topology. In this case, we see far-away, but we must rely on our neighbor to forward any requests to Far-Away. If our NSA encounters an STP that lives in Far-Away, and our peering table has no trust with Far-Away, then we must send our request to our neighbor who acts as intermediary. (In point of fact, our neighbor acts no differently than it would for any other request - it sees the Far-Away STP and forwards the request likewise.)
This may generate another topology requirement- that of reachability. I.e. how do we describe the set of points (STPs) reachable within (or through) a given domain? We have to recognize that our reachable end systems or STPs will almost immediately be counted in the thousands. We probably need some sort of hierarchichal naming scheme.
thoughts? Jerry
Guy Roberts wrote:
I suggest the following 10 requirements as a starter:
Requirement 1: The model should be able to describe a grouping of network resources that are owned and controlled by a single provider or NSA. (I will call this a NETWORK for the moment)
Requirement 2: The model should be able to describe a grouping of NETWORKs. (e.g. a federation of providers with shared policy)
Requirement 3: The model should be able to describe resources (ports/points) in a NETWORK that are available for connecting to other NETWORKs. (I will call this a network connection point NCP for the moment)
Requirement 4: These NPs should be able to be performed at the end of a link that is internal to the domain as well as to ports on a device. (in my opinion the NCP on a link requirement needs a use-case)
Requirement 5: The model should be able to describe an arbitrary number of layers of logical ports within a NCP.
Requirement 6: The model should be able to describe connectivity between NETWORKs. (I will call this inter network connection (INCs) for the moment)
Requirement 7: The model should be able to describe groups of INCs.
Requirement 8: The resources that make up INCs should have ownership by a clearly identifiable provider. (i.e. resources without NSA ownership are not allowed). (note: Does this also include the patch cord between providers?)
Requirement 9: The model should allow policy to be assigned to INCs, even where the INC is wholly or partly made up of passive resources.
Requirement 10: The model should be able to fully describe a circuit (i.e. NSI service) that transits the topology.
Any thoughts on these and other requirements would be helpful.
Guy
-----Original Message-----
From: Freek Dijkstra [mailto:Freek.Dijkstra@sara.nl]
Sent: 22 February 2010 13:52
To: NSI WG
Cc: Guy Roberts; Jeroen van der Ham; John Vollbrecht
Subject: Re: [Nsi-wg] NML topology
Can I summarize this discussion as follows?
Requirement: It should be possible to assign a policy to an
(interdomain) link.
Of course, I can think of a solution (e.g. make that link part of a
topology, like John's second picture, assign the topology to a
networkdomain, and assign a policy to that networkdomain). However, this
seems out of scope. I think the best way forward is to describe this and
other requirements and forward them to the NML and ask the NML folks to
come up with a solution for the requirement. I also wholeheartedly
invite all NSI group members to become a "NML folk" too by joining the
NML list!
Regards,
Freek
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>
A couple things we should also put on a discussion agenda: - NSA Connection request handling - Connection decomposition and manipulation semantics. I think understanding these in a clearer detail will aid our discussion on our topology needs. So here is a long but hopefully useful proposal for NSA request handling. Please try to wade thru the pseudo code below. I think this will frame much of our disussions on both topology and pathfinding. Upon receiving a Connection Request... - The local NSA examines the request and decomposes the request into a set of /n/ sub-requests defined by explicit hops in the originating PO. Each sub-request has only an ingress and egress STP. For example: PO={A>B>C>D} decomposes to (A>B, (B>C), (C>D) . - For each sub-request, do { If ( ingressSTP is local ) then { If (egressSTP is local ) then { /* subrequest is completely local */ PO[i]= reservePath (localRM, ingress > egress) /* local PathFinding */ } else { /* ingress is local, egress point is remote, */ /* Here we split the sub-request into a local segment and a remote segment */ find local exitSTP towards remote egressSTP; /* this is PF */ find neighbor entranceSTP == local exitSTP; /* a "Point" would work nice here */ decompose request into LocalSeg:=(ingress>exit) and RemoteSeg:=(entrance>egress); /* process local segment */ POlocal = reservePath (localRM, ingress > exit) /* local PathFinding */ if (POlocal != True) /* a local path was not found to the selected exit point */ then { either try another exit point, or error; } /* process remote segment */ POremote = ConnectRequest( NSA(entrance), entrance > egress); /* send to neighborNSA */ if ( POremote != True ) then error; /* the remote path failed */ PO[i] = POlocal : POremote; /* concatenate local and remote POs */ } } else { /* ingressSTP is remote, so forward the sub-request to/towards the ingressNSA */ PO[i] = ConnectRequest( NSA(ingressSTP), ingress > egress); } } } /* end DO */ - If any PO[] is null/error, then release all good POs, and return error response to user. /* no complete end-to-end path */ - Finally, concatenate all the returned result POs = PO[0]:PO[1]: ... :PO{n]; and return the result to the requester. Note: the above handling only applies path decomposition semantics to the requester's Path Object and distributes the resulting sub-requests to/towards NSAs of the ingressSTPs in each sub-request. Except as noted below, there was really no PathFinding involved. The one trick in the pseudo code above is where a sub-request is split between the local domain (ingressSTP) and a remote domain (egressSTP). In this case, we want to decompose this segment further into a purely local sub-request (which the local RM can handle), and a purely remote sub-request (which we'll send to that NSA). These two segments must share an edge point between the local domain and the next adjacent domain. To do this, the local NSA must find an "exitSTP" leading to the remote STP, and insert it into the PO as an explicit intermediate hop. Then the sub-request gets decomposed into a wholly local sub-request, and a wholly remote sub-request. The only topology information required to do this local/remote decomposition is to know a) which exit point to use, and b) what the equivalent [entrance] STP is called in the adjacent domain. The latter is easy - its exchanged as part of bringing up each inter-domain connection and is stored in the local topology DB or peering table. But the former, choosing an exit point, is more involved: we could either do an exhaustive PathFinder search of the global topology (very expensive), or we could accumulate reachability information at each edge node incrementally as additional topology information is learned (i.e. as new STPs and Domains come online.) the reachability info can then be used to prune the PF search tree vastly improving its effectiveness. ...how Reachability info gets distributed/learned is not important right now, but reachability is one important means of pruning the search tree in path computations. We could punt and just say "PathFinding [magicaly] chooses an exit point" and leave it to the PathFindng working group to decide the details.... Nevertheless, for NSI, the local NSA must be able to a) map an STP to its native domain and thus find and/or establish trust with its NSA, or b) map an STP to a directly connected intermediary NSA who offers to act on its behalf. The former method may still not provide enough topology info to build a comlete and valid topology graph unless the topology offered by the owner NSA is related somehow to topology already known to be contiguous to local domain. (I.e. a directory look up may assign ownership, but doesn't necessarilly provide topology information relevant to the question at hand...how do I get there?) So: How does a local NSA find out which NSA "owns" an STP? I assert this "ownership" information is really just "reachability" information. All the local NSA really needs to now is what is the relationship is between an STP and an NSA -> in their own local topologyDB <-. To put it another way: the local NSA has some view of the world as represented in its local topology DB (hopefully this is summarized somehow, but in any case, the local topologyDB represents all that the localNSA knows about the world. ) It may be the case that the localNSA learned [somehow] that a domain "Far-Away" is connected to a domain "NeighborA" which is connected to local Domain. And thru the same mechanism learned of a set of STPs that exist in Far-Away. So localNSA has a trust relation with NeighborA, but may/maynot have such with Far-Away's NSA. It doesn't really matter. When localNSA learns of Far-Away, localNSA could try to establish trust. If FarAway accepts it, then local NSA could pose a tree decomposition across NeighborA and then across Far-Away. If FarAway does not trust localNSA (or vice versa) we can still decompose a chain request to NeighborA who evidently *does* have a trust relationship with FarAway, and let them work things out. A lot of making the tree and chain model workable relies on topology distribution protocol... Short of describing that protocol, we can identify requirements, and assert that they exist, and based on that, the NSI NSA can function thuswise... Thinks for reading so much technical details... Jerry Guy Roberts wrote:
Jerry,
I like what you have done here -- the point is to first state clearly what the NSI 'Connection Service' needs to do, and then to derive the topology requirements from these service functions.
Will you be able to make tomorrow's call? I would like to make this make this a topic for discussion.
Guy
*From:* Jerry Sobieski [mailto:jerry@nordu.net] *Sent:* 23 February 2010 04:46 *To:* Guy Roberts *Cc:* Freek Dijkstra; NSI WG *Subject:* Re: [Nsi-wg] NML topology
Good idea Guy...I have a couple of posts...here is the first:.
I suggest we focus on which NSI service request parameters or semantics have topological significance and what those are. For instance:
*1. NSI: A Connection request must, at a minimum, specify the ingress point and the egress point. The Connection request may also specify intermediate transit points for the connection. The semantics of loose hop request is PO={A,B,C}, is equivalent to Connection A>B concatenated with Connection B>C. *
Topo Requirement: Each of these "point" identifiers must uniquely determine and map to a location in the transport topology. What is the NSI definition of a "point"used in this context? It seems to correspond to our STP discussion...so we need to decide what a point in the Path Object really refers to topologically.
*2. NSI: A Provider NSA is responsible for decomposing the Connection request (into piecewise segments defined by the PO) and forwarding sub-requests to other service agents as it deems appropriate or necessary, and insuring the returned sub-segments can be assembled into a single fully satisfied Connection and returning that Connection result to the Requesting NSA. *
Requirement: Define how the NSA handles Connection requests. a) The NSA decomposes the request into a set of sub-segments as defined by the PO. b) The NSA must forward each sub-request to/towards the NSA that owns the ingress STP of the sub-request, /[Here is where topology comes into play - how do we know where to send a request? Must map STP to NSA owner or have reachability in the topology..] / c) If an NSA receives a request whose ingress STP is in the local Domain, the NSA invokes the PathFinder to reserve a Path towards the next STP [/NSA must be able to recognize STPs in its local domain/] d) Upon successful reservation, the returned POs of the sub-requests are merged into a single PO and returned to the originating Requester.
*3. NSI: Upon successfull reservation, a Path Object is returned to the user describing the resulting Path. This PO will contain the STPs stipulated by the originating request, and will contain either a) STPs of the as-built Connection, or b) named Path Object(s) for opaque as-built information.*
Requirement: Path Object definition. Including opaque Named POs that are only revealed to authorized requesters. A PO must contain STPs, but must also include a Named PO - which must carry some authorization policy. How do these Named POs get resolved? what do they look like, how are names constructed, etc.
The above notion that we forward requests from one NSA to another based upon some ownership means we must define that ownership concept. Therein lies the notions of grouping resources into Networks, and a single NSA King for each Network kingdom :-) If STPs are part of that group, what are they and how do we summarize such info?
However, we do not have a trust relationship with all NSAs - its scaling problem. We must assume that we will connect directly with some neighbor Networks, and have a trusted relationship with them. But we will not (cannot) directly connect to every network, and therefore some such "far-away" networks will not recognize and trust our local NSA. For these latter cases, the only way we will know of that far-away domain is if one of our direct neighbors offers to act as transit to to Far-Away domain by announcing all or some of Far-Away's topology. In this case, we see far-away, but we must rely on our neighbor to forward any requests to Far-Away. If our NSA encounters an STP that lives in Far-Away, and our peering table has no trust with Far-Away, then we must send our request to our neighbor who acts as intermediary. (In point of fact, our neighbor acts no differently than it would for any other request - it sees the Far-Away STP and forwards the request likewise.)
This may generate another topology requirement- that of reachability. I.e. how do we describe the set of points (STPs) reachable within (or through) a given domain? We have to recognize that our reachable end systems or STPs will almost immediately be counted in the thousands. We probably need some sort of hierarchichal naming scheme.
thoughts? Jerry
Guy Roberts wrote:
I suggest the following 10 requirements as a starter:
Requirement 1: The model should be able to describe a grouping of network resources that are owned and controlled by a single provider or NSA. (I will call this a NETWORK for the moment)
Requirement 2: The model should be able to describe a grouping of NETWORKs. (e.g. a federation of providers with shared policy)
Requirement 3: The model should be able to describe resources (ports/points) in a NETWORK that are available for connecting to other NETWORKs. (I will call this a network connection point NCP for the moment)
Requirement 4: These NPs should be able to be performed at the end of a link that is internal to the domain as well as to ports on a device. (in my opinion the NCP on a link requirement needs a use-case)
Requirement 5: The model should be able to describe an arbitrary number of layers of logical ports within a NCP.
Requirement 6: The model should be able to describe connectivity between NETWORKs. (I will call this inter network connection (INCs) for the moment)
Requirement 7: The model should be able to describe groups of INCs.
Requirement 8: The resources that make up INCs should have ownership by a clearly identifiable provider. (i.e. resources without NSA ownership are not allowed). (note: Does this also include the patch cord between providers?)
Requirement 9: The model should allow policy to be assigned to INCs, even where the INC is wholly or partly made up of passive resources.
Requirement 10: The model should be able to fully describe a circuit (i.e. NSI service) that transits the topology.
Any thoughts on these and other requirements would be helpful.
Guy
-----Original Message-----
From: Freek Dijkstra [mailto:Freek.Dijkstra@sara.nl]
Sent: 22 February 2010 13:52
To: NSI WG
Cc: Guy Roberts; Jeroen van der Ham; John Vollbrecht
Subject: Re: [Nsi-wg] NML topology
Can I summarize this discussion as follows?
Requirement: It should be possible to assign a policy to an
(interdomain) link.
Of course, I can think of a solution (e.g. make that link part of a
topology, like John's second picture, assign the topology to a
networkdomain, and assign a policy to that networkdomain). However, this
seems out of scope. I think the best way forward is to describe this and
other requirements and forward them to the NML and ask the NML folks to
come up with a solution for the requirement. I also wholeheartedly
invite all NSI group members to become a "NML folk" too by joining the
NML list!
Regards,
Freek
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>
Hi Jerry, I basically agree with your pseudo code. But this else clouse seems to be based on the chain model and not applicable for the tree model.
else { /* ingressSTP is remote, so forward the sub-request to/towards the ingressNSA */ PO[i] = ConnectRequest( NSA(ingressSTP), ingress > egress); }
Tomohiro On Tue, 23 Feb 2010 18:20:28 -0500 Jerry Sobieski <jerry@nordu.net> wrote:
A couple things we should also put on a discussion agenda: - NSA Connection request handling - Connection decomposition and manipulation semantics.
I think understanding these in a clearer detail will aid our discussion on our topology needs.
So here is a long but hopefully useful proposal for NSA request handling. Please try to wade thru the pseudo code below. I think this will frame much of our disussions on both topology and pathfinding.
Upon receiving a Connection Request... - The local NSA examines the request and decomposes the request into a set of /n/ sub-requests defined by explicit hops in the originating PO. Each sub-request has only an ingress and egress STP. For example: PO={A>B>C>D} decomposes to (A>B, (B>C), (C>D) . - For each sub-request, do { If ( ingressSTP is local ) then { If (egressSTP is local ) then { /* subrequest is completely local */ PO[i]= reservePath (localRM, ingress > egress) /* local PathFinding */ } else { /* ingress is local, egress point is remote, */
/* Here we split the sub-request into a local segment and a remote segment */ find local exitSTP towards remote egressSTP; /* this is PF */ find neighbor entranceSTP == local exitSTP; /* a "Point" would work nice here */ decompose request into LocalSeg:=(ingress>exit) and RemoteSeg:=(entrance>egress);
/* process local segment */ POlocal = reservePath (localRM, ingress > exit) /* local PathFinding */ if (POlocal != True) /* a local path was not found to the selected exit point */ then { either try another exit point, or error; }
/* process remote segment */ POremote = ConnectRequest( NSA(entrance), entrance > egress); /* send to neighborNSA */ if ( POremote != True ) then error; /* the remote path failed */ PO[i] = POlocal : POremote; /* concatenate local and remote POs */ } } else { /* ingressSTP is remote, so forward the sub-request to/towards the ingressNSA */ PO[i] = ConnectRequest( NSA(ingressSTP), ingress > egress); } } } /* end DO */ - If any PO[] is null/error, then release all good POs, and return error response to user. /* no complete end-to-end path */ - Finally, concatenate all the returned result POs = PO[0]:PO[1]: ... :PO{n]; and return the result to the requester.
Note: the above handling only applies path decomposition semantics to the requester's Path Object and distributes the resulting sub-requests to/towards NSAs of the ingressSTPs in each sub-request. Except as noted below, there was really no PathFinding involved.
The one trick in the pseudo code above is where a sub-request is split between the local domain (ingressSTP) and a remote domain (egressSTP). In this case, we want to decompose this segment further into a purely local sub-request (which the local RM can handle), and a purely remote sub-request (which we'll send to that NSA). These two segments must share an edge point between the local domain and the next adjacent domain. To do this, the local NSA must find an "exitSTP" leading to the remote STP, and insert it into the PO as an explicit intermediate hop. Then the sub-request gets decomposed into a wholly local sub-request, and a wholly remote sub-request.
The only topology information required to do this local/remote decomposition is to know a) which exit point to use, and b) what the equivalent [entrance] STP is called in the adjacent domain. The latter is easy - its exchanged as part of bringing up each inter-domain connection and is stored in the local topology DB or peering table. But the former, choosing an exit point, is more involved: we could either do an exhaustive PathFinder search of the global topology (very expensive), or we could accumulate reachability information at each edge node incrementally as additional topology information is learned (i.e. as new STPs and Domains come online.) the reachability info can then be used to prune the PF search tree vastly improving its effectiveness.
...how Reachability info gets distributed/learned is not important right now, but reachability is one important means of pruning the search tree in path computations. We could punt and just say "PathFinding [magicaly] chooses an exit point" and leave it to the PathFindng working group to decide the details....
Nevertheless, for NSI, the local NSA must be able to a) map an STP to its native domain and thus find and/or establish trust with its NSA, or b) map an STP to a directly connected intermediary NSA who offers to act on its behalf. The former method may still not provide enough topology info to build a comlete and valid topology graph unless the topology offered by the owner NSA is related somehow to topology already known to be contiguous to local domain. (I.e. a directory look up may assign ownership, but doesn't necessarilly provide topology information relevant to the question at hand...how do I get there?)
So: How does a local NSA find out which NSA "owns" an STP? I assert this "ownership" information is really just "reachability" information. All the local NSA really needs to now is what is the relationship is between an STP and an NSA -> in their own local topologyDB <-. To put it another way: the local NSA has some view of the world as represented in its local topology DB (hopefully this is summarized somehow, but in any case, the local topologyDB represents all that the localNSA knows about the world. ) It may be the case that the localNSA learned [somehow] that a domain "Far-Away" is connected to a domain "NeighborA" which is connected to local Domain. And thru the same mechanism learned of a set of STPs that exist in Far-Away. So localNSA has a trust relation with NeighborA, but may/maynot have such with Far-Away's NSA. It doesn't really matter. When localNSA learns of Far-Away, localNSA could try to establish trust. If FarAway accepts it, then local NSA could pose a tree decomposition across NeighborA and then across Far-Away. If FarAway does not trust localNSA (or vice versa) we can still decompose a chain request to NeighborA who evidently *does* have a trust relationship with FarAway, and let them work things out.
A lot of making the tree and chain model workable relies on topology distribution protocol... Short of describing that protocol, we can identify requirements, and assert that they exist, and based on that, the NSI NSA can function thuswise...
Thinks for reading so much technical details...
Jerry
Guy Roberts wrote:
Jerry,
I like what you have done here -- the point is to first state clearly what the NSI 'Connection Service' needs to do, and then to derive the topology requirements from these service functions.
Will you be able to make tomorrow's call? I would like to make this make this a topic for discussion.
Guy
*From:* Jerry Sobieski [mailto:jerry@nordu.net] *Sent:* 23 February 2010 04:46 *To:* Guy Roberts *Cc:* Freek Dijkstra; NSI WG *Subject:* Re: [Nsi-wg] NML topology
Good idea Guy...I have a couple of posts...here is the first:.
I suggest we focus on which NSI service request parameters or semantics have topological significance and what those are. For instance:
*1. NSI: A Connection request must, at a minimum, specify the ingress point and the egress point. The Connection request may also specify intermediate transit points for the connection. The semantics of loose hop request is PO={A,B,C}, is equivalent to Connection A>B concatenated with Connection B>C. *
Topo Requirement: Each of these "point" identifiers must uniquely determine and map to a location in the transport topology. What is the NSI definition of a "point"used in this context? It seems to correspond to our STP discussion...so we need to decide what a point in the Path Object really refers to topologically.
*2. NSI: A Provider NSA is responsible for decomposing the Connection request (into piecewise segments defined by the PO) and forwarding sub-requests to other service agents as it deems appropriate or necessary, and insuring the returned sub-segments can be assembled into a single fully satisfied Connection and returning that Connection result to the Requesting NSA. *
Requirement: Define how the NSA handles Connection requests. a) The NSA decomposes the request into a set of sub-segments as defined by the PO. b) The NSA must forward each sub-request to/towards the NSA that owns the ingress STP of the sub-request, /[Here is where topology comes into play - how do we know where to send a request? Must map STP to NSA owner or have reachability in the topology..] / c) If an NSA receives a request whose ingress STP is in the local Domain, the NSA invokes the PathFinder to reserve a Path towards the next STP [/NSA must be able to recognize STPs in its local domain/] d) Upon successful reservation, the returned POs of the sub-requests are merged into a single PO and returned to the originating Requester.
*3. NSI: Upon successfull reservation, a Path Object is returned to the user describing the resulting Path. This PO will contain the STPs stipulated by the originating request, and will contain either a) STPs of the as-built Connection, or b) named Path Object(s) for opaque as-built information.*
Requirement: Path Object definition. Including opaque Named POs that are only revealed to authorized requesters. A PO must contain STPs, but must also include a Named PO - which must carry some authorization policy. How do these Named POs get resolved? what do they look like, how are names constructed, etc.
The above notion that we forward requests from one NSA to another based upon some ownership means we must define that ownership concept. Therein lies the notions of grouping resources into Networks, and a single NSA King for each Network kingdom :-) If STPs are part of that group, what are they and how do we summarize such info?
However, we do not have a trust relationship with all NSAs - its scaling problem. We must assume that we will connect directly with some neighbor Networks, and have a trusted relationship with them. But we will not (cannot) directly connect to every network, and therefore some such "far-away" networks will not recognize and trust our local NSA. For these latter cases, the only way we will know of that far-away domain is if one of our direct neighbors offers to act as transit to to Far-Away domain by announcing all or some of Far-Away's topology. In this case, we see far-away, but we must rely on our neighbor to forward any requests to Far-Away. If our NSA encounters an STP that lives in Far-Away, and our peering table has no trust with Far-Away, then we must send our request to our neighbor who acts as intermediary. (In point of fact, our neighbor acts no differently than it would for any other request - it sees the Far-Away STP and forwards the request likewise.)
This may generate another topology requirement- that of reachability. I.e. how do we describe the set of points (STPs) reachable within (or through) a given domain? We have to recognize that our reachable end systems or STPs will almost immediately be counted in the thousands. We probably need some sort of hierarchichal naming scheme.
thoughts? Jerry
Guy Roberts wrote:
I suggest the following 10 requirements as a starter:
Requirement 1: The model should be able to describe a grouping of network resources that are owned and controlled by a single provider or NSA. (I will call this a NETWORK for the moment)
Requirement 2: The model should be able to describe a grouping of NETWORKs. (e.g. a federation of providers with shared policy)
Requirement 3: The model should be able to describe resources (ports/points) in a NETWORK that are available for connecting to other NETWORKs. (I will call this a network connection point NCP for the moment)
Requirement 4: These NPs should be able to be performed at the end of a link that is internal to the domain as well as to ports on a device. (in my opinion the NCP on a link requirement needs a use-case)
Requirement 5: The model should be able to describe an arbitrary number of layers of logical ports within a NCP.
Requirement 6: The model should be able to describe connectivity between NETWORKs. (I will call this inter network connection (INCs) for the moment)
Requirement 7: The model should be able to describe groups of INCs.
Requirement 8: The resources that make up INCs should have ownership by a clearly identifiable provider. (i.e. resources without NSA ownership are not allowed). (note: Does this also include the patch cord between providers?)
Requirement 9: The model should allow policy to be assigned to INCs, even where the INC is wholly or partly made up of passive resources.
Requirement 10: The model should be able to fully describe a circuit (i.e. NSI service) that transits the topology.
Any thoughts on these and other requirements would be helpful.
Guy
-----Original Message-----
From: Freek Dijkstra [mailto:Freek.Dijkstra@sara.nl]
Sent: 22 February 2010 13:52
To: NSI WG
Cc: Guy Roberts; Jeroen van der Ham; John Vollbrecht
Subject: Re: [Nsi-wg] NML topology
Can I summarize this discussion as follows?
Requirement: It should be possible to assign a policy to an
(interdomain) link.
Of course, I can think of a solution (e.g. make that link part of a
topology, like John's second picture, assign the topology to a
networkdomain, and assign a policy to that networkdomain). However, this
seems out of scope. I think the best way forward is to describe this and
other requirements and forward them to the NML and ask the NML folks to
come up with a solution for the requirement. I also wholeheartedly
invite all NSI group members to become a "NML folk" too by joining the
NML list!
Regards,
Freek
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>
Hi Tomohiro - This is a very astute observation. Two changes/clarifications need to be made to enable the tree/chain model option: 1.) In order to do tree processing, we need to expand the PO to include the interdomain connector points. The local NSA can invoke an interdomain PathFinder to expand the Path Object. This statement: PO[i] = ConnectRequest( NSA(ingressSTP), ingress > egress); would change to read something like: id-PO = (ingress > egress); /* expand PO = (nextDomain/ingress > nextDomain/exit > anotherDomain/exit > endDomain/egress) */ if(method==tree) then id-PO = InterdomainExpansion(ingress > egress); PO[i] = ConnectRequest( NSA(ingressSTP), id-PO ); If the local NSA elects to expand the remote PO, we get a tree model PO. If the local NSA does not expand the PO we have a chain model PO. Its up to the local NSA to decide which approach to use. 2.) The only other mod we need is to process each interation of the outer "do{}" block asynchronously - i.e. in parallel. If we are running tree mode, each sub-request is made in parallel; if we are running in chain mode, we do the local reservation and then send teh remaining request downstream. Selecting the correct method will be based on available topo information, complexity of the topology, and utilization rate (resource availability) of the transport plane - a study in best practice. There are some nuances associated with this defined process that I won't elaborate on here, but I believe this pseudo code is [now] basically correct, though there are a few things I would do to clean it up if we were writing real code. I hope this addressed your issue. Jerry Tomohiro Kudoh wrote:
Hi Jerry,
I basically agree with your pseudo code. But this else clouse seems to be based on the chain model and not applicable for the tree model.
else { /* ingressSTP is remote, so forward the sub-request to/towards the ingressNSA */ PO[i] = ConnectRequest( NSA(ingressSTP), ingress > egress); }
Tomohiro
On Tue, 23 Feb 2010 18:20:28 -0500 Jerry Sobieski <jerry@nordu.net> wrote:
A couple things we should also put on a discussion agenda: - NSA Connection request handling - Connection decomposition and manipulation semantics.
I think understanding these in a clearer detail will aid our discussion on our topology needs.
So here is a long but hopefully useful proposal for NSA request handling. Please try to wade thru the pseudo code below. I think this will frame much of our disussions on both topology and pathfinding.
Upon receiving a Connection Request... - The local NSA examines the request and decomposes the request into a set of /n/ sub-requests defined by explicit hops in the originating PO. Each sub-request has only an ingress and egress STP. For example: PO={A>B>C>D} decomposes to (A>B, (B>C), (C>D) . - For each sub-request, do { If ( ingressSTP is local ) then { If (egressSTP is local ) then { /* subrequest is completely local */ PO[i]= reservePath (localRM, ingress > egress) /* local PathFinding */ } else { /* ingress is local, egress point is remote, */
/* Here we split the sub-request into a local segment and a remote segment */ find local exitSTP towards remote egressSTP; /* this is PF */ find neighbor entranceSTP == local exitSTP; /* a "Point" would work nice here */ decompose request into LocalSeg:=(ingress>exit) and RemoteSeg:=(entrance>egress);
/* process local segment */ POlocal = reservePath (localRM, ingress > exit) /* local PathFinding */ if (POlocal != True) /* a local path was not found to the selected exit point */ then { either try another exit point, or error; }
/* process remote segment */ POremote = ConnectRequest( NSA(entrance), entrance > egress); /* send to neighborNSA */ if ( POremote != True ) then error; /* the remote path failed */ PO[i] = POlocal : POremote; /* concatenate local and remote POs */ } } else { /* ingressSTP is remote, so forward the sub-request to/towards the ingressNSA */ PO[i] = ConnectRequest( NSA(ingressSTP), ingress > egress); } } } /* end DO */ - If any PO[] is null/error, then release all good POs, and return error response to user. /* no complete end-to-end path */ - Finally, concatenate all the returned result POs = PO[0]:PO[1]: ... :PO{n]; and return the result to the requester.
Note: the above handling only applies path decomposition semantics to the requester's Path Object and distributes the resulting sub-requests to/towards NSAs of the ingressSTPs in each sub-request. Except as noted below, there was really no PathFinding involved.
The one trick in the pseudo code above is where a sub-request is split between the local domain (ingressSTP) and a remote domain (egressSTP). In this case, we want to decompose this segment further into a purely local sub-request (which the local RM can handle), and a purely remote sub-request (which we'll send to that NSA). These two segments must share an edge point between the local domain and the next adjacent domain. To do this, the local NSA must find an "exitSTP" leading to the remote STP, and insert it into the PO as an explicit intermediate hop. Then the sub-request gets decomposed into a wholly local sub-request, and a wholly remote sub-request.
The only topology information required to do this local/remote decomposition is to know a) which exit point to use, and b) what the equivalent [entrance] STP is called in the adjacent domain. The latter is easy - its exchanged as part of bringing up each inter-domain connection and is stored in the local topology DB or peering table. But the former, choosing an exit point, is more involved: we could either do an exhaustive PathFinder search of the global topology (very expensive), or we could accumulate reachability information at each edge node incrementally as additional topology information is learned (i.e. as new STPs and Domains come online.) the reachability info can then be used to prune the PF search tree vastly improving its effectiveness.
...how Reachability info gets distributed/learned is not important right now, but reachability is one important means of pruning the search tree in path computations. We could punt and just say "PathFinding [magicaly] chooses an exit point" and leave it to the PathFindng working group to decide the details....
Nevertheless, for NSI, the local NSA must be able to a) map an STP to its native domain and thus find and/or establish trust with its NSA, or b) map an STP to a directly connected intermediary NSA who offers to act on its behalf. The former method may still not provide enough topology info to build a comlete and valid topology graph unless the topology offered by the owner NSA is related somehow to topology already known to be contiguous to local domain. (I.e. a directory look up may assign ownership, but doesn't necessarilly provide topology information relevant to the question at hand...how do I get there?)
So: How does a local NSA find out which NSA "owns" an STP? I assert this "ownership" information is really just "reachability" information. All the local NSA really needs to now is what is the relationship is between an STP and an NSA -> in their own local topologyDB <-. To put it another way: the local NSA has some view of the world as represented in its local topology DB (hopefully this is summarized somehow, but in any case, the local topologyDB represents all that the localNSA knows about the world. ) It may be the case that the localNSA learned [somehow] that a domain "Far-Away" is connected to a domain "NeighborA" which is connected to local Domain. And thru the same mechanism learned of a set of STPs that exist in Far-Away. So localNSA has a trust relation with NeighborA, but may/maynot have such with Far-Away's NSA. It doesn't really matter. When localNSA learns of Far-Away, localNSA could try to establish trust. If FarAway accepts it, then local NSA could pose a tree decomposition across NeighborA and then across Far-Away. If FarAway does not trust localNSA (or vice versa) we can still decompose a chain request to NeighborA who evidently *does* have a trust relationship with FarAway, and let them work things out.
A lot of making the tree and chain model workable relies on topology distribution protocol... Short of describing that protocol, we can identify requirements, and assert that they exist, and based on that, the NSI NSA can function thuswise...
Thinks for reading so much technical details...
Jerry
Guy Roberts wrote:
Jerry,
I like what you have done here -- the point is to first state clearly what the NSI 'Connection Service' needs to do, and then to derive the topology requirements from these service functions.
Will you be able to make tomorrow's call? I would like to make this make this a topic for discussion.
Guy
*From:* Jerry Sobieski [mailto:jerry@nordu.net] *Sent:* 23 February 2010 04:46 *To:* Guy Roberts *Cc:* Freek Dijkstra; NSI WG *Subject:* Re: [Nsi-wg] NML topology
Good idea Guy...I have a couple of posts...here is the first:.
I suggest we focus on which NSI service request parameters or semantics have topological significance and what those are. For instance:
*1. NSI: A Connection request must, at a minimum, specify the ingress point and the egress point. The Connection request may also specify intermediate transit points for the connection. The semantics of loose hop request is PO={A,B,C}, is equivalent to Connection A>B concatenated with Connection B>C. *
Topo Requirement: Each of these "point" identifiers must uniquely determine and map to a location in the transport topology. What is the NSI definition of a "point"used in this context? It seems to correspond to our STP discussion...so we need to decide what a point in the Path Object really refers to topologically.
*2. NSI: A Provider NSA is responsible for decomposing the Connection request (into piecewise segments defined by the PO) and forwarding sub-requests to other service agents as it deems appropriate or necessary, and insuring the returned sub-segments can be assembled into a single fully satisfied Connection and returning that Connection result to the Requesting NSA. *
Requirement: Define how the NSA handles Connection requests. a) The NSA decomposes the request into a set of sub-segments as defined by the PO. b) The NSA must forward each sub-request to/towards the NSA that owns the ingress STP of the sub-request, /[Here is where topology comes into play - how do we know where to send a request? Must map STP to NSA owner or have reachability in the topology..] / c) If an NSA receives a request whose ingress STP is in the local Domain, the NSA invokes the PathFinder to reserve a Path towards the next STP [/NSA must be able to recognize STPs in its local domain/] d) Upon successful reservation, the returned POs of the sub-requests are merged into a single PO and returned to the originating Requester.
*3. NSI: Upon successfull reservation, a Path Object is returned to the user describing the resulting Path. This PO will contain the STPs stipulated by the originating request, and will contain either a) STPs of the as-built Connection, or b) named Path Object(s) for opaque as-built information.*
Requirement: Path Object definition. Including opaque Named POs that are only revealed to authorized requesters. A PO must contain STPs, but must also include a Named PO - which must carry some authorization policy. How do these Named POs get resolved? what do they look like, how are names constructed, etc.
The above notion that we forward requests from one NSA to another based upon some ownership means we must define that ownership concept. Therein lies the notions of grouping resources into Networks, and a single NSA King for each Network kingdom :-) If STPs are part of that group, what are they and how do we summarize such info?
However, we do not have a trust relationship with all NSAs - its scaling problem. We must assume that we will connect directly with some neighbor Networks, and have a trusted relationship with them. But we will not (cannot) directly connect to every network, and therefore some such "far-away" networks will not recognize and trust our local NSA. For these latter cases, the only way we will know of that far-away domain is if one of our direct neighbors offers to act as transit to to Far-Away domain by announcing all or some of Far-Away's topology. In this case, we see far-away, but we must rely on our neighbor to forward any requests to Far-Away. If our NSA encounters an STP that lives in Far-Away, and our peering table has no trust with Far-Away, then we must send our request to our neighbor who acts as intermediary. (In point of fact, our neighbor acts no differently than it would for any other request - it sees the Far-Away STP and forwards the request likewise.)
This may generate another topology requirement- that of reachability. I.e. how do we describe the set of points (STPs) reachable within (or through) a given domain? We have to recognize that our reachable end systems or STPs will almost immediately be counted in the thousands. We probably need some sort of hierarchichal naming scheme.
thoughts? Jerry
Guy Roberts wrote:
I suggest the following 10 requirements as a starter:
Requirement 1: The model should be able to describe a grouping of network resources that are owned and controlled by a single provider or NSA. (I will call this a NETWORK for the moment)
Requirement 2: The model should be able to describe a grouping of NETWORKs. (e.g. a federation of providers with shared policy)
Requirement 3: The model should be able to describe resources (ports/points) in a NETWORK that are available for connecting to other NETWORKs. (I will call this a network connection point NCP for the moment)
Requirement 4: These NPs should be able to be performed at the end of a link that is internal to the domain as well as to ports on a device. (in my opinion the NCP on a link requirement needs a use-case)
Requirement 5: The model should be able to describe an arbitrary number of layers of logical ports within a NCP.
Requirement 6: The model should be able to describe connectivity between NETWORKs. (I will call this inter network connection (INCs) for the moment)
Requirement 7: The model should be able to describe groups of INCs.
Requirement 8: The resources that make up INCs should have ownership by a clearly identifiable provider. (i.e. resources without NSA ownership are not allowed). (note: Does this also include the patch cord between providers?)
Requirement 9: The model should allow policy to be assigned to INCs, even where the INC is wholly or partly made up of passive resources.
Requirement 10: The model should be able to fully describe a circuit (i.e. NSI service) that transits the topology.
Any thoughts on these and other requirements would be helpful.
Guy
-----Original Message-----
From: Freek Dijkstra [mailto:Freek.Dijkstra@sara.nl]
Sent: 22 February 2010 13:52
To: NSI WG
Cc: Guy Roberts; Jeroen van der Ham; John Vollbrecht
Subject: Re: [Nsi-wg] NML topology
Can I summarize this discussion as follows?
Requirement: It should be possible to assign a policy to an
(interdomain) link.
Of course, I can think of a solution (e.g. make that link part of a
topology, like John's second picture, assign the topology to a
networkdomain, and assign a policy to that networkdomain). However, this
seems out of scope. I think the best way forward is to describe this and
other requirements and forward them to the NML and ask the NML folks to
come up with a solution for the requirement. I also wholeheartedly
invite all NSI group members to become a "NML folk" too by joining the
NML list!
Regards,
Freek
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hi Jerry, all,
id-PO = (ingress > egress); /* expand PO = (nextDomain/ingress > nextDomain/exit > anotherDomain/exit > endDomain/egress) */ if(method==tree) then id-PO = InterdomainExpansion(ingress > egress); PO[i] = ConnectRequest( NSA(ingressSTP), id-PO );
If the local NSA elects to expand the remote PO, we get a tree model PO. If the local NSA does not expand the PO we have a chain model PO. Its up to the local NSA to decide which approach to use.
Elegant way to fix it :). However, this means the process should be iterated up to the moment that the last expansion only provides local NSA as a result. Shouldn't it be faster to have the inter-domain path finding done at the very beginning, avoiding iteration? It seems to me that hierarchical (tree) deployments using this algorithm would follow a chain-like path finding model, loosing the advantage of being the whole-inter-domain-topology-knowing hierarchy parent. Anyway, I highly appreciate (and learn from!) the discussion we're having here but aren't we rowing far from the definition of the interface itself? Regards, -- Joan A. García-Espín CTX, i2CAT Foundation El 25/02/2010, a las 7:32, Jerry Sobieski escribió:
Hi Tomohiro - This is a very astute observation. Two changes/clarifications need to be made to enable the tree/chain model option:
1.) In order to do tree processing, we need to expand the PO to include the interdomain connector points. The local NSA can invoke an interdomain PathFinder to expand the Path Object. This statement: PO[i] = ConnectRequest( NSA(ingressSTP), ingress > egress);
would change to read something like:
id-PO = (ingress > egress); /* expand PO = (nextDomain/ingress > nextDomain/exit > anotherDomain/ exit > endDomain/egress) */ if(method==tree) then id-PO = InterdomainExpansion(ingress > egress); PO[i] = ConnectRequest( NSA(ingressSTP), id-PO );
If the local NSA elects to expand the remote PO, we get a tree model PO. If the local NSA does not expand the PO we have a chain model PO. Its up to the local NSA to decide which approach to use.
2.) The only other mod we need is to process each interation of the outer "do{}" block asynchronously - i.e. in parallel. If we are running tree mode, each sub-request is made in parallel; if we are running in chain mode, we do the local reservation and then send teh remaining request downstream. Selecting the correct method will be based on available topo information, complexity of the topology, and utilization rate (resource availability) of the transport plane - a study in best practice.
There are some nuances associated with this defined process that I won't elaborate on here, but I believe this pseudo code is [now] basically correct, though there are a few things I would do to clean it up if we were writing real code.
I hope this addressed your issue. Jerry
Tomohiro Kudoh wrote:
Hi Jerry,
I basically agree with your pseudo code. But this else clouse seems to be based on the chain model and not applicable for the tree model.
else { /* ingressSTP is remote, so forward the sub-request to/towards the ingressNSA */ PO[i] = ConnectRequest( NSA(ingressSTP), ingress > egress); }
Tomohiro
On Tue, 23 Feb 2010 18:20:28 -0500 Jerry Sobieski <jerry@nordu.net> wrote:
A couple things we should also put on a discussion agenda: - NSA Connection request handling - Connection decomposition and manipulation semantics.
I think understanding these in a clearer detail will aid our discussion on our topology needs.
So here is a long but hopefully useful proposal for NSA request handling. Please try to wade thru the pseudo code below. I think this will frame much of our disussions on both topology and pathfinding.
Upon receiving a Connection Request... - The local NSA examines the request and decomposes the request into a set of /n/ sub-requests defined by explicit hops in the originating PO. Each sub-request has only an ingress and egress STP. For example: PO={A>B>C>D} decomposes to (A>B, (B>C), (C>D) . - For each sub-request, do { If ( ingressSTP is local ) then { If (egressSTP is local ) then { /* subrequest is completely local */ PO[i]= reservePath (localRM, ingress > egress) /* local PathFinding */ } else { /* ingress is local, egress point is remote, */
/* Here we split the sub-request into a local segment and a remote segment */ find local exitSTP towards remote egressSTP; /* this is PF */ find neighbor entranceSTP == local exitSTP; /* a "Point" would work nice here */ decompose request into LocalSeg:=(ingress>exit) and RemoteSeg:=(entrance>egress);
/* process local segment */ POlocal = reservePath (localRM, ingress > exit) /* local PathFinding */ if (POlocal != True) /* a local path was not found to the selected exit point */ then { either try another exit point, or error; }
/* process remote segment */ POremote = ConnectRequest( NSA(entrance), entrance > egress); /* send to neighborNSA */ if ( POremote != True ) then error; /* the remote path failed */ PO[i] = POlocal : POremote; /* concatenate local and remote POs */ } } else { /* ingressSTP is remote, so forward the sub-request to/towards the ingressNSA */ PO[i] = ConnectRequest( NSA(ingressSTP), ingress > egress); } } } /* end DO */ - If any PO[] is null/error, then release all good POs, and return error response to user. /* no complete end-to-end path */ - Finally, concatenate all the returned result POs = PO[0]:PO[1]: ... :PO{n]; and return the result to the requester.
Note: the above handling only applies path decomposition semantics to the requester's Path Object and distributes the resulting sub- requests to/towards NSAs of the ingressSTPs in each sub-request. Except as noted below, there was really no PathFinding involved.
The one trick in the pseudo code above is where a sub-request is split between the local domain (ingressSTP) and a remote domain (egressSTP). In this case, we want to decompose this segment further into a purely local sub-request (which the local RM can handle), and a purely remote sub-request (which we'll send to that NSA). These two segments must share an edge point between the local domain and the next adjacent domain. To do this, the local NSA must find an "exitSTP" leading to the remote STP, and insert it into the PO as an explicit intermediate hop. Then the sub-request gets decomposed into a wholly local sub- request, and a wholly remote sub-request.
The only topology information required to do this local/remote decomposition is to know a) which exit point to use, and b) what the equivalent [entrance] STP is called in the adjacent domain. The latter is easy - its exchanged as part of bringing up each inter-domain connection and is stored in the local topology DB or peering table. But the former, choosing an exit point, is more involved: we could either do an exhaustive PathFinder search of the global topology (very expensive), or we could accumulate reachability information at each edge node incrementally as additional topology information is learned (i.e. as new STPs and Domains come online.) the reachability info can then be used to prune the PF search tree vastly improving its effectiveness.
...how Reachability info gets distributed/learned is not important right now, but reachability is one important means of pruning the search tree in path computations. We could punt and just say "PathFinding [magicaly] chooses an exit point" and leave it to the PathFindng working group to decide the details....
Nevertheless, for NSI, the local NSA must be able to a) map an STP to its native domain and thus find and/or establish trust with its NSA, or b) map an STP to a directly connected intermediary NSA who offers to act on its behalf. The former method may still not provide enough topology info to build a comlete and valid topology graph unless the topology offered by the owner NSA is related somehow to topology already known to be contiguous to local domain. (I.e. a directory look up may assign ownership, but doesn't necessarilly provide topology information relevant to the question at hand...how do I get there?)
So: How does a local NSA find out which NSA "owns" an STP? I assert this "ownership" information is really just "reachability" information. All the local NSA really needs to now is what is the relationship is between an STP and an NSA -> in their own local topologyDB <-. To put it another way: the local NSA has some view of the world as represented in its local topology DB (hopefully this is summarized somehow, but in any case, the local topologyDB represents all that the localNSA knows about the world. ) It may be the case that the localNSA learned [somehow] that a domain "Far-Away" is connected to a domain "NeighborA" which is connected to local Domain. And thru the same mechanism learned of a set of STPs that exist in Far-Away. So localNSA has a trust relation with NeighborA, but may/maynot have such with Far-Away's NSA. It doesn't really matter. When localNSA learns of Far-Away, localNSA could try to establish trust. If FarAway accepts it, then local NSA could pose a tree decomposition across NeighborA and then across Far-Away. If FarAway does not trust localNSA (or vice versa) we can still decompose a chain request to NeighborA who evidently *does* have a trust relationship with FarAway, and let them work things out.
A lot of making the tree and chain model workable relies on topology distribution protocol... Short of describing that protocol, we can identify requirements, and assert that they exist, and based on that, the NSI NSA can function thuswise...
Thinks for reading so much technical details...
Jerry
Guy Roberts wrote:
Jerry,
I like what you have done here -- the point is to first state clearly what the NSI 'Connection Service' needs to do, and then to derive the topology requirements from these service functions.
Will you be able to make tomorrow's call? I would like to make this make this a topic for discussion.
Guy
*From:* Jerry Sobieski [mailto:jerry@nordu.net] *Sent:* 23 February 2010 04:46 *To:* Guy Roberts *Cc:* Freek Dijkstra; NSI WG *Subject:* Re: [Nsi-wg] NML topology
Good idea Guy...I have a couple of posts...here is the first:.
I suggest we focus on which NSI service request parameters or semantics have topological significance and what those are. For instance:
*1. NSI: A Connection request must, at a minimum, specify the ingress point and the egress point. The Connection request may also specify intermediate transit points for the connection. The semantics of loose hop request is PO={A,B,C}, is equivalent to Connection A>B concatenated with Connection B>C. *
Topo Requirement: Each of these "point" identifiers must uniquely determine and map to a location in the transport topology. What is the NSI definition of a "point"used in this context? It seems to correspond to our STP discussion...so we need to decide what a point in the Path Object really refers to topologically.
*2. NSI: A Provider NSA is responsible for decomposing the Connection request (into piecewise segments defined by the PO) and forwarding sub-requests to other service agents as it deems appropriate or necessary, and insuring the returned sub-segments can be assembled into a single fully satisfied Connection and returning that Connection result to the Requesting NSA. *
Requirement: Define how the NSA handles Connection requests. a) The NSA decomposes the request into a set of sub-segments as defined by the PO. b) The NSA must forward each sub-request to/towards the NSA that owns the ingress STP of the sub-request, /[Here is where topology comes into play - how do we know where to send a request? Must map STP to NSA owner or have reachability in the topology..] / c) If an NSA receives a request whose ingress STP is in the local Domain, the NSA invokes the PathFinder to reserve a Path towards the next STP [/NSA must be able to recognize STPs in its local domain/] d) Upon successful reservation, the returned POs of the sub-requests are merged into a single PO and returned to the originating Requester.
*3. NSI: Upon successfull reservation, a Path Object is returned to the user describing the resulting Path. This PO will contain the STPs stipulated by the originating request, and will contain either a) STPs of the as-built Connection, or b) named Path Object(s) for opaque as-built information.*
Requirement: Path Object definition. Including opaque Named POs that are only revealed to authorized requesters. A PO must contain STPs, but must also include a Named PO - which must carry some authorization policy. How do these Named POs get resolved? what do they look like, how are names constructed, etc.
The above notion that we forward requests from one NSA to another based upon some ownership means we must define that ownership concept. Therein lies the notions of grouping resources into Networks, and a single NSA King for each Network kingdom :-) If STPs are part of that group, what are they and how do we summarize such info?
However, we do not have a trust relationship with all NSAs - its scaling problem. We must assume that we will connect directly with some neighbor Networks, and have a trusted relationship with them. But we will not (cannot) directly connect to every network, and therefore some such "far-away" networks will not recognize and trust our local NSA. For these latter cases, the only way we will know of that far-away domain is if one of our direct neighbors offers to act as transit to to Far-Away domain by announcing all or some of Far-Away's topology. In this case, we see far-away, but we must rely on our neighbor to forward any requests to Far-Away. If our NSA encounters an STP that lives in Far-Away, and our peering table has no trust with Far-Away, then we must send our request to our neighbor who acts as intermediary. (In point of fact, our neighbor acts no differently than it would for any other request - it sees the Far- Away STP and forwards the request likewise.)
This may generate another topology requirement- that of reachability. I.e. how do we describe the set of points (STPs) reachable within (or through) a given domain? We have to recognize that our reachable end systems or STPs will almost immediately be counted in the thousands. We probably need some sort of hierarchichal naming scheme.
thoughts? Jerry
Guy Roberts wrote:
I suggest the following 10 requirements as a starter:
Requirement 1: The model should be able to describe a grouping of network resources that are owned and controlled by a single provider or NSA. (I will call this a NETWORK for the moment)
Requirement 2: The model should be able to describe a grouping of NETWORKs. (e.g. a federation of providers with shared policy)
Requirement 3: The model should be able to describe resources (ports/points) in a NETWORK that are available for connecting to other NETWORKs. (I will call this a network connection point NCP for the moment)
Requirement 4: These NPs should be able to be performed at the end of a link that is internal to the domain as well as to ports on a device. (in my opinion the NCP on a link requirement needs a use-case)
Requirement 5: The model should be able to describe an arbitrary number of layers of logical ports within a NCP.
Requirement 6: The model should be able to describe connectivity between NETWORKs. (I will call this inter network connection (INCs) for the moment)
Requirement 7: The model should be able to describe groups of INCs.
Requirement 8: The resources that make up INCs should have ownership by a clearly identifiable provider. (i.e. resources without NSA ownership are not allowed). (note: Does this also include the patch cord between providers?)
Requirement 9: The model should allow policy to be assigned to INCs, even where the INC is wholly or partly made up of passive resources.
Requirement 10: The model should be able to fully describe a circuit (i.e. NSI service) that transits the topology.
Any thoughts on these and other requirements would be helpful.
Guy
-----Original Message-----
From: Freek Dijkstra [mailto:Freek.Dijkstra@sara.nl]
Sent: 22 February 2010 13:52
To: NSI WG
Cc: Guy Roberts; Jeroen van der Ham; John Vollbrecht
Subject: Re: [Nsi-wg] NML topology
Can I summarize this discussion as follows?
Requirement: It should be possible to assign a policy to an
(interdomain) link.
Of course, I can think of a solution (e.g. make that link part of a
topology, like John's second picture, assign the topology to a
networkdomain, and assign a policy to that networkdomain). However, this
seems out of scope. I think the best way forward is to describe this and
other requirements and forward them to the NML and ask the NML folks to
come up with a solution for the requirement. I also wholeheartedly
invite all NSI group members to become a "NML folk" too by joining the
NML list!
Regards,
Freek
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>
_______________________________________________ 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- Yes...we have drifted a bit far from shore in these discussions - albeit they do serve to show some of the prior work and "nuanced complexities" (:-) of things we as humans think of as self evident and straightforward when mapped to computational processes where nothing can be assumed and everything must be explicitly addressed. Let me elaborate on the iteration issue: In order to form a valid sub-request, each sub-request must /at a minimum/ specify its end points. Selecting the ingress point for each segment depends upon knowing the egress point for the preceding segment. So you have to resolve the previous segment first...and so on up the line until you reach the local domain. However, if we receive a request that has a set of intermediate STPs in the PO, we are required to transit these STPs - they are *required* STPs. Since these are necessary, the dependency on the adjacent segments is removed, and each segment can be treated as a separate and independent Path Request and can be performed asynchroously with the other sub-requests. All of the sub-requests defined by the original PO can be performed in parallel and *must* come back confirmed for the overall request to be complete and confirmed back to the original requester. (Note: we still have to sequentially go thru the PO to set up the individual tree subrequests...but this is very cheap and fast.) But this all relies on the fact that the STPs were present apriori in the original request PO. Which begs the question how did the requesting NSA know to select these STPs as transit points? However, there is no assurance to the local provider NSA that the transit STPs specified in the PO are the *only* interdomain links the request will need to transit. So the local NSA decompose the original request into the segments defined by the request, but then he still needs to run the described psuedo code on each subsegment to discover any additionional interdomain links. If the local NSA decides to add an STP to the PO for any reason (say, to decompose a subsegment into local and remote components) then that STP is not a "required" STP under the constraints specified in the original request. This STP is a *candidate* STP. And so, if both [candidate] segments sharing that STP can not be confirmed, then that STP must be discarded and another candidate STP must be selected and the process repeated until all candidate STPs have been considered or a succesful end-to-end Path was found. (This is pathfinding). Worse, in a recursive fashion, a candidate STP cannot be confirmed if is part of a segment that shares an endpoint with another unconfirmed candidate segment. (Ugh!) So... If we assert having [somehow] selected the domains you want to transit (and selected the ingress and/or egress points for each) in some process of high level PathFinding, you *can* make the reservation requests in parallel. However, if any reservation fails, then the adjacent segment reservations are of questionable utility and may (probably) need to be torn down and alternate path(s) explored. This topic of path planning involves issues like crankback, near/far bypass, etc. For the time being, IMO, we should not endorse any cranlback or alternate path discovery algorithms or any PathFinding algorithm at all - We just need to support Tree and Chain handling. Finally, if we try to parallelize the selection of downstream domains, you have to ask yourself what is the selection criteria? From a possibly very large and arbitrary set of domains, how do we sort them out into relevant and irrelevant domains? Do we use reachability? authorization? capacity? schedule? Random Guess? You need *all* of the request criteria satisfied before confirming a Path so the order in which you inspect the constraints is important and the only real choice we have as NSA. This constraint ordering is found by Best Practice (heuristics), and varies from network to network. The prefered (most common) ordering is that which prunes the search space earliest/fastest, This almost always means finding a candidate Path with reachability from the starting point first - since this immediately prunes 99% of the topology from consideration. And after each candidate STP/segment is qualified and reserved, the search starts over. The point I want to make here is that we need to really appreciate the scope of the PathFinding process - even at this stage of the NSI discussions. We need to be thinking how we organize the NSI to aid the PF process with clarity and well defined concepts and architecture. Hope this helps - enjoy the weekend! Jerry Joan A. García-Espín wrote:
Hi Jerry, all,
id-PO = (ingress > egress); /* expand PO = (nextDomain/ingress > nextDomain/exit > anotherDomain/exit > endDomain/egress) */ if(method==tree) then id-PO = InterdomainExpansion(ingress > egress); PO[i] = ConnectRequest( NSA(ingressSTP), id-PO );
If the local NSA elects to expand the remote PO, we get a tree model PO. If the local NSA does not expand the PO we have a chain model PO. Its up to the local NSA to decide which approach to use.
Elegant way to fix it :). However, this means the process should be iterated up to the moment that the last expansion only provides local NSA as a result. Shouldn't it be faster to have the inter-domain path finding done at the very beginning, avoiding iteration? It seems to me that hierarchical (tree) deployments using this algorithm would follow a chain-like path finding model, loosing the advantage of being the whole-inter-domain-topology-knowing hierarchy parent.
Anyway, I highly appreciate (and learn from!) the discussion we're having here but aren't we rowing far from the definition of the interface itself?
Regards, -- Joan A. García-Espín CTX, i2CAT Foundation
El 25/02/2010, a las 7:32, Jerry Sobieski escribió:
Hi Tomohiro - This is a very astute observation. Two changes/clarifications need to be made to enable the tree/chain model option:
1.) In order to do tree processing, we need to expand the PO to include the interdomain connector points. The local NSA can invoke an interdomain PathFinder to expand the Path Object. This statement: PO[i] = ConnectRequest( NSA(ingressSTP), ingress > egress);
would change to read something like:
id-PO = (ingress > egress); /* expand PO = (nextDomain/ingress > nextDomain/exit > anotherDomain/exit > endDomain/egress) */ if(method==tree) then id-PO = InterdomainExpansion(ingress > egress); PO[i] = ConnectRequest( NSA(ingressSTP), id-PO );
If the local NSA elects to expand the remote PO, we get a tree model PO. If the local NSA does not expand the PO we have a chain model PO. Its up to the local NSA to decide which approach to use.
2.) The only other mod we need is to process each interation of the outer "do{}" block asynchronously - i.e. in parallel. If we are running tree mode, each sub-request is made in parallel; if we are running in chain mode, we do the local reservation and then send teh remaining request downstream. Selecting the correct method will be based on available topo information, complexity of the topology, and utilization rate (resource availability) of the transport plane - a study in best practice.
There are some nuances associated with this defined process that I won't elaborate on here, but I believe this pseudo code is [now] basically correct, though there are a few things I would do to clean it up if we were writing real code.
I hope this addressed your issue. Jerry
Tomohiro Kudoh wrote:
Hi Jerry,
I basically agree with your pseudo code. But this else clouse seems to be based on the chain model and not applicable for the tree model.
else { /* ingressSTP is remote, so forward the sub-request to/towards the ingressNSA */ PO[i] = ConnectRequest( NSA(ingressSTP), ingress > egress); }
Tomohiro
On Tue, 23 Feb 2010 18:20:28 -0500 Jerry Sobieski <jerry@nordu.net> wrote:
A couple things we should also put on a discussion agenda: - NSA Connection request handling - Connection decomposition and manipulation semantics.
I think understanding these in a clearer detail will aid our discussion on our topology needs.
So here is a long but hopefully useful proposal for NSA request handling. Please try to wade thru the pseudo code below. I think this will frame much of our disussions on both topology and pathfinding.
Upon receiving a Connection Request... - The local NSA examines the request and decomposes the request into a set of /n/ sub-requests defined by explicit hops in the originating PO. Each sub-request has only an ingress and egress STP. For example: PO={A>B>C>D} decomposes to (A>B, (B>C), (C>D) . - For each sub-request, do { If ( ingressSTP is local ) then { If (egressSTP is local ) then { /* subrequest is completely local */ PO[i]= reservePath (localRM, ingress > egress) /* local PathFinding */ } else { /* ingress is local, egress point is remote, */
/* Here we split the sub-request into a local segment and a remote segment */ find local exitSTP towards remote egressSTP; /* this is PF */ find neighbor entranceSTP == local exitSTP; /* a "Point" would work nice here */ decompose request into LocalSeg:=(ingress>exit) and RemoteSeg:=(entrance>egress);
/* process local segment */ POlocal = reservePath (localRM, ingress > exit) /* local PathFinding */ if (POlocal != True) /* a local path was not found to the selected exit point */ then { either try another exit point, or error; }
/* process remote segment */ POremote = ConnectRequest( NSA(entrance), entrance > egress); /* send to neighborNSA */ if ( POremote != True ) then error; /* the remote path failed */ PO[i] = POlocal : POremote; /* concatenate local and remote POs */ } } else { /* ingressSTP is remote, so forward the sub-request to/towards the ingressNSA */ PO[i] = ConnectRequest( NSA(ingressSTP), ingress > egress); } } } /* end DO */ - If any PO[] is null/error, then release all good POs, and return error response to user. /* no complete end-to-end path */ - Finally, concatenate all the returned result POs = PO[0]:PO[1]: ... :PO{n]; and return the result to the requester.
Note: the above handling only applies path decomposition semantics to the requester's Path Object and distributes the resulting sub-requests to/towards NSAs of the ingressSTPs in each sub-request. Except as noted below, there was really no PathFinding involved.
The one trick in the pseudo code above is where a sub-request is split between the local domain (ingressSTP) and a remote domain (egressSTP). In this case, we want to decompose this segment further into a purely local sub-request (which the local RM can handle), and a purely remote sub-request (which we'll send to that NSA). These two segments must share an edge point between the local domain and the next adjacent domain. To do this, the local NSA must find an "exitSTP" leading to the remote STP, and insert it into the PO as an explicit intermediate hop. Then the sub-request gets decomposed into a wholly local sub-request, and a wholly remote sub-request.
The only topology information required to do this local/remote decomposition is to know a) which exit point to use, and b) what the equivalent [entrance] STP is called in the adjacent domain. The latter is easy - its exchanged as part of bringing up each inter-domain connection and is stored in the local topology DB or peering table. But the former, choosing an exit point, is more involved: we could either do an exhaustive PathFinder search of the global topology (very expensive), or we could accumulate reachability information at each edge node incrementally as additional topology information is learned (i.e. as new STPs and Domains come online.) the reachability info can then be used to prune the PF search tree vastly improving its effectiveness.
...how Reachability info gets distributed/learned is not important right now, but reachability is one important means of pruning the search tree in path computations. We could punt and just say "PathFinding [magicaly] chooses an exit point" and leave it to the PathFindng working group to decide the details....
Nevertheless, for NSI, the local NSA must be able to a) map an STP to its native domain and thus find and/or establish trust with its NSA, or b) map an STP to a directly connected intermediary NSA who offers to act on its behalf. The former method may still not provide enough topology info to build a comlete and valid topology graph unless the topology offered by the owner NSA is related somehow to topology already known to be contiguous to local domain. (I.e. a directory look up may assign ownership, but doesn't necessarilly provide topology information relevant to the question at hand...how do I get there?)
So: How does a local NSA find out which NSA "owns" an STP? I assert this "ownership" information is really just "reachability" information. All the local NSA really needs to now is what is the relationship is between an STP and an NSA -> in their own local topologyDB <-. To put it another way: the local NSA has some view of the world as represented in its local topology DB (hopefully this is summarized somehow, but in any case, the local topologyDB represents all that the localNSA knows about the world. ) It may be the case that the localNSA learned [somehow] that a domain "Far-Away" is connected to a domain "NeighborA" which is connected to local Domain. And thru the same mechanism learned of a set of STPs that exist in Far-Away. So localNSA has a trust relation with NeighborA, but may/maynot have such with Far-Away's NSA. It doesn't really matter. When localNSA learns of Far-Away, localNSA could try to establish trust. If FarAway accepts it, then local NSA could pose a tree decomposition across NeighborA and then across Far-Away. If FarAway does not trust localNSA (or vice versa) we can still decompose a chain request to NeighborA who evidently *does* have a trust relationship with FarAway, and let them work things out.
A lot of making the tree and chain model workable relies on topology distribution protocol... Short of describing that protocol, we can identify requirements, and assert that they exist, and based on that, the NSI NSA can function thuswise...
Thinks for reading so much technical details...
Jerry
Guy Roberts wrote:
Jerry,
I like what you have done here -- the point is to first state clearly what the NSI 'Connection Service' needs to do, and then to derive the topology requirements from these service functions.
Will you be able to make tomorrow's call? I would like to make this make this a topic for discussion.
Guy
*From:* Jerry Sobieski [mailto:jerry@nordu.net] *Sent:* 23 February 2010 04:46 *To:* Guy Roberts *Cc:* Freek Dijkstra; NSI WG *Subject:* Re: [Nsi-wg] NML topology
Good idea Guy...I have a couple of posts...here is the first:.
I suggest we focus on which NSI service request parameters or semantics have topological significance and what those are. For instance:
*1. NSI: A Connection request must, at a minimum, specify the ingress point and the egress point. The Connection request may also specify intermediate transit points for the connection. The semantics of loose hop request is PO={A,B,C}, is equivalent to Connection A>B concatenated with Connection B>C. *
Topo Requirement: Each of these "point" identifiers must uniquely determine and map to a location in the transport topology. What is the NSI definition of a "point"used in this context? It seems to correspond to our STP discussion...so we need to decide what a point in the Path Object really refers to topologically.
*2. NSI: A Provider NSA is responsible for decomposing the Connection request (into piecewise segments defined by the PO) and forwarding sub-requests to other service agents as it deems appropriate or necessary, and insuring the returned sub-segments can be assembled into a single fully satisfied Connection and returning that Connection result to the Requesting NSA. *
Requirement: Define how the NSA handles Connection requests. a) The NSA decomposes the request into a set of sub-segments as defined by the PO. b) The NSA must forward each sub-request to/towards the NSA that owns the ingress STP of the sub-request, /[Here is where topology comes into play - how do we know where to send a request? Must map STP to NSA owner or have reachability in the topology..] / c) If an NSA receives a request whose ingress STP is in the local Domain, the NSA invokes the PathFinder to reserve a Path towards the next STP [/NSA must be able to recognize STPs in its local domain/] d) Upon successful reservation, the returned POs of the sub-requests are merged into a single PO and returned to the originating Requester.
*3. NSI: Upon successfull reservation, a Path Object is returned to the user describing the resulting Path. This PO will contain the STPs stipulated by the originating request, and will contain either a) STPs of the as-built Connection, or b) named Path Object(s) for opaque as-built information.*
Requirement: Path Object definition. Including opaque Named POs that are only revealed to authorized requesters. A PO must contain STPs, but must also include a Named PO - which must carry some authorization policy. How do these Named POs get resolved? what do they look like, how are names constructed, etc.
The above notion that we forward requests from one NSA to another based upon some ownership means we must define that ownership concept. Therein lies the notions of grouping resources into Networks, and a single NSA King for each Network kingdom :-) If STPs are part of that group, what are they and how do we summarize such info?
However, we do not have a trust relationship with all NSAs - its scaling problem. We must assume that we will connect directly with some neighbor Networks, and have a trusted relationship with them. But we will not (cannot) directly connect to every network, and therefore some such "far-away" networks will not recognize and trust our local NSA. For these latter cases, the only way we will know of that far-away domain is if one of our direct neighbors offers to act as transit to to Far-Away domain by announcing all or some of Far-Away's topology. In this case, we see far-away, but we must rely on our neighbor to forward any requests to Far-Away. If our NSA encounters an STP that lives in Far-Away, and our peering table has no trust with Far-Away, then we must send our request to our neighbor who acts as intermediary. (In point of fact, our neighbor acts no differently than it would for any other request - it sees the Far-Away STP and forwards the request likewise.)
This may generate another topology requirement- that of reachability. I.e. how do we describe the set of points (STPs) reachable within (or through) a given domain? We have to recognize that our reachable end systems or STPs will almost immediately be counted in the thousands. We probably need some sort of hierarchichal naming scheme.
thoughts? Jerry
Guy Roberts wrote:
I suggest the following 10 requirements as a starter:
Requirement 1: The model should be able to describe a grouping of network resources that are owned and controlled by a single provider or NSA. (I will call this a NETWORK for the moment)
Requirement 2: The model should be able to describe a grouping of NETWORKs. (e.g. a federation of providers with shared policy)
Requirement 3: The model should be able to describe resources (ports/points) in a NETWORK that are available for connecting to other NETWORKs. (I will call this a network connection point NCP for the moment)
Requirement 4: These NPs should be able to be performed at the end of a link that is internal to the domain as well as to ports on a device. (in my opinion the NCP on a link requirement needs a use-case)
Requirement 5: The model should be able to describe an arbitrary number of layers of logical ports within a NCP.
Requirement 6: The model should be able to describe connectivity between NETWORKs. (I will call this inter network connection (INCs) for the moment)
Requirement 7: The model should be able to describe groups of INCs.
Requirement 8: The resources that make up INCs should have ownership by a clearly identifiable provider. (i.e. resources without NSA ownership are not allowed). (note: Does this also include the patch cord between providers?)
Requirement 9: The model should allow policy to be assigned to INCs, even where the INC is wholly or partly made up of passive resources.
Requirement 10: The model should be able to fully describe a circuit (i.e. NSI service) that transits the topology.
Any thoughts on these and other requirements would be helpful.
Guy
-----Original Message-----
From: Freek Dijkstra [mailto:Freek.Dijkstra@sara.nl]
Sent: 22 February 2010 13:52
To: NSI WG
Cc: Guy Roberts; Jeroen van der Ham; John Vollbrecht
Subject: Re: [Nsi-wg] NML topology
Can I summarize this discussion as follows?
Requirement: It should be possible to assign a policy to an
(interdomain) link.
Of course, I can think of a solution (e.g. make that link part of a
topology, like John's second picture, assign the topology to a
networkdomain, and assign a policy to that networkdomain). However, this
seems out of scope. I think the best way forward is to describe this and
other requirements and forward them to the NML and ask the NML folks to
come up with a solution for the requirement. I also wholeheartedly
invite all NSI group members to become a "NML folk" too by joining the
NML list!
Regards,
Freek
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org <mailto:nsi-wg@ogf.org>
_______________________________________________ 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 all- Here are some thoughts on why I think the notion of a "Point" does have merit in an NSI topology model: "Nodes" and "Links" in our current discussions represent resource objects that exist in the physical transport topology. Both objects have physical characteristics (e.g. latency, a transfer function, bit error rates, etc.), and both have "Ports" (I/O interfaces) that move data streams into or out of each respective object. And, a resource could be a grouped and summarized object that hides a great deal of internal topology and/or performs a complex transfer function (more on this in a moment). It makes sense (and reflects reality) to say that all Nodes and Links are in fact owned by one domain or another...no such thing really as a free Link. We should be able to represent this in our model. I think a "Point" construct - i.e. a Touch Point or Tangent Point does this rather nicely. (Admittedly, I had to be convinced myself that such a construct was useful and could work.) So, given that two networks meet at such a point, how do we indicate that a Port from network A connects to a Link in network B? A convenient way that has been explored in the literature is a derivative graph (sometimes called a Channel Graph): each physical component of the topology (i.e. the Nodes and Links) is reduced to a generalized "Resource" object with a corresponding set of Ports. For instance a Link becomes a Resource with one input Port and one output Port and some physical characteristic(s) e.g. latency. Ports are joined together through this notion of a "Point". A Point is a /topological/ object that ties one or more Ports together indicating that they represent the same location topologically speaking (physically speaking, this might indicate that a fiber Link is plugged into a switch Node/Port interface) In a sense, a Point has no physical characteristics besides the Ports that make up the Point. Resources ( physical Nodes and Links) have physical characteristics associated with them. But our Point construct simply ties a number of Ports together - the characteristics of that Point are wholly derived from the characteristics of the constituent Ports. A Point could in fact reference other Points as well as Ports - any/all such Points and their consituent Ports are all topologically equivalent. In a practical sense, these Points could in fact be the Service Termination/Transit Points (STPs) we have alluded to in our discussions. (Even if we ultimately name them something else, the idea remains the same.) Further, the recognition of a Point object allows us to locate all Ports that are joined together (think of a broadcast domain). A Port construct would refer to a Point construct that would in turn refer to (list) all Ports that are joined at that Point. A Path can then be found by searching from Start Point to Port to Resource to Port to Point to Port to Resource to Port to Point to ... very clean...(IMO). We can think of a Point as a topological construct that expresses purely connectivity (topological equivalence), where as a Link is a physical resource object or node in the physical network topology. This subtle and seemingly minor distinction keeps all of our physical constraints in the Resources and/or their Ports, and puts the topological structure in the Points. (It could be argued that this reduction actually means a Point should be called a link, but good grief...:-) In the Inter-Domain topology papers and standards, a "point" where two networks meet makes a certain amount of sense...). Finally, a set of contiguous Resources could be grouped together into a larger object. This larger object could be another Resource object - thus creating a nesting of Resources to summarize and/or hide complexity. There needs to be a method of mapping internal Ports to the external Ports of such nested Resource objects - Points do this nicely without requiring internal Port references to leak out to external agents... These larger scale Resource objects could be refered to as "Network" objects if we chose - it does not change their structure or function, but indicates a relationship of the larger scoped object to the internal components. E.g. "A Network is a Resource object made up of other [sub-]Resources." This modified NSI topology model may be implemented internally differently in various NSI implementations. Its not absolutely necessary that NSI use the NML topo model in its pristine form to describe our architecture. Nor is it necessarily the case that NML needs to make any changes to their model to accomodate NSI model. In fact, it is not it required that NSI implementations use either the NSI or NML topology internally in an implementation. NSI only needs to state the topology model it uses to describe the NSI architecture semantics and protocol - which does not place any requirements on implementers to build internal structures that must resemble this. How an implementation represents its topology internally is not our concern- the implementers just need to understand how they map NSI semantics to their implementation so that they express the same semantic value. I think if we describe the NSI topology as a reduction of physical Nodes and Links to the their Resource state, then a topology of Resources, Ports, and tangent Points is (IMO) easily understood. I include a diagram of how all this can be diagramatically denoted... Hope this helps... Jerry Jeroen van der Ham wrote:
On 21/02/2010 18:20, John Vollbrecht wrote:
Attached is set of ppt slides to describe interdomain topology. I hope this helps - it is based on conversations in the NML group, and is my understanding of what the Glossary of terms that Guy is reviewing (and I think will review next Wed).
I just want to clarify my view of the conversation we have had in the NML group about this issue. This was mainly a discussion between myself and John wherein I tried to understand the NSI issue of describing inter-domain topologies.
The current NML topology model does not have "Points". Nor do we currently have plans to add them. *Unless* there is a use-case showing the need of Points, which clearly outlines why it is not possible to describe domain boundaries with the current NML Topology model. So far, I have not seen such a clear and valid use-case for "Points".
Jeroen. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Interestingly this reminds me of a very long ongoing discussion in my group about the visibility of exchanges in a topologyy graph. In the internet (BGP) topology one does not see the AMS-IX exchange, because it operates completely at layer2. Its presence (in the BGP topology that is ;-) ) is also not needed as it plays no role in the forwarding tables. However in the glif lightpath world we need something to note the presence of exchanges. So there are more options for that. One can be the "points", other is obviously a multi layer topology description that describes the lower layer exchange point. Best regards, Cees. On Feb 22, 2010, at 12:52 PM, Jerry Sobieski wrote:
Hi all-
Here are some thoughts on why I think the notion of a "Point" does have merit in an NSI topology model:
"Nodes" and "Links" in our current discussions represent resource objects that exist in the physical transport topology. Both objects have physical characteristics (e.g. latency, a transfer function, bit error rates, etc.), and both have "Ports" (I/O interfaces) that move data streams into or out of each respective object. And, a resource could be a grouped and summarized object that hides a great deal of internal topology and/or performs a complex transfer function (more on this in a moment).
It makes sense (and reflects reality) to say that all Nodes and Links are in fact owned by one domain or another...no such thing really as a free Link. We should be able to represent this in our model. I think a "Point" construct - i.e. a Touch Point or Tangent Point does this rather nicely. (Admittedly, I had to be convinced myself that such a construct was useful and could work.)
So, given that two networks meet at such a point, how do we indicate that a Port from network A connects to a Link in network B?
A convenient way that has been explored in the literature is a derivative graph (sometimes called a Channel Graph): each physical component of the topology (i.e. the Nodes and Links) is reduced to a generalized "Resource" object with a corresponding set of Ports. For instance a Link becomes a Resource with one input Port and one output Port and some physical characteristic(s) e.g. latency. Ports are joined together through this notion of a "Point". A Point is a topological object that ties one or more Ports together indicating that they represent the same location topologically speaking (physically speaking, this might indicate that a fiber Link is plugged into a switch Node/Port interface)
In a sense, a Point has no physical characteristics besides the Ports that make up the Point. Resources ( physical Nodes and Links) have physical characteristics associated with them. But our Point construct simply ties a number of Ports together - the characteristics of that Point are wholly derived from the characteristics of the constituent Ports. A Point could in fact reference other Points as well as Ports - any/all such Points and their consituent Ports are all topologically equivalent.
In a practical sense, these Points could in fact be the Service Termination/Transit Points (STPs) we have alluded to in our discussions. (Even if we ultimately name them something else, the idea remains the same.) Further, the recognition of a Point object allows us to locate all Ports that are joined together (think of a broadcast domain). A Port construct would refer to a Point construct that would in turn refer to (list) all Ports that are joined at that Point. A Path can then be found by searching from Start Point to Port to Resource to Port to Point to Port to Resource to Port to Point to ... very clean...(IMO).
We can think of a Point as a topological construct that expresses purely connectivity (topological equivalence), where as a Link is a physical resource object or node in the physical network topology. This subtle and seemingly minor distinction keeps all of our physical constraints in the Resources and/or their Ports, and puts the topological structure in the Points. (It could be argued that this reduction actually means a Point should be called a link, but good grief...:-) In the Inter-Domain topology papers and standards, a "point" where two networks meet makes a certain amount of sense...).
Finally, a set of contiguous Resources could be grouped together into a larger object. This larger object could be another Resource object - thus creating a nesting of Resources to summarize and/or hide complexity. There needs to be a method of mapping internal Ports to the external Ports of such nested Resource objects - Points do this nicely without requiring internal Port references to leak out to external agents... These larger scale Resource objects could be refered to as "Network" objects if we chose - it does not change their structure or function, but indicates a relationship of the larger scoped object to the internal components. E.g. "A Network is a Resource object made up of other [sub-]Resources."
This modified NSI topology model may be implemented internally differently in various NSI implementations. Its not absolutely necessary that NSI use the NML topo model in its pristine form to describe our architecture. Nor is it necessarily the case that NML needs to make any changes to their model to accomodate NSI model. In fact, it is not it required that NSI implementations use either the NSI or NML topology internally in an implementation. NSI only needs to state the topology model it uses to describe the NSI architecture semantics and protocol - which does not place any requirements on implementers to build internal structures that must resemble this. How an implementation represents its topology internally is not our concern- the implementers just need to understand how they map NSI semantics to their implementation so that they express the same semantic value.
I think if we describe the NSI topology as a reduction of physical Nodes and Links to the their Resource state, then a topology of Resources, Ports, and tangent Points is (IMO) easily understood. I include a diagram of how all this can be diagramatically denoted...
Hope this helps... Jerry
Jeroen van der Ham wrote:
On 21/02/2010 18:20, John Vollbrecht wrote:
Attached is set of ppt slides to describe interdomain topology. I hope this helps - it is based on conversations in the NML group, and is my understanding of what the Glossary of terms that Guy is reviewing (and I think will review next Wed).
I just want to clarify my view of the conversation we have had in the NML group about this issue. This was mainly a discussion between myself and John wherein I tried to understand the NSI issue of describing inter-domain topologies.
The current NML topology model does not have "Points". Nor do we currently have plans to add them. *Unless* there is a use-case showing the need of Points, which clearly outlines why it is not possible to describe domain boundaries with the current NML Topology model. So far, I have not seen such a clear and valid use-case for "Points".
Jeroen. _______________________________________________ nsi-wg mailing list
nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
<Derived Graphs.pptx>_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hi All, Jerry I like the way you have differentiated the concepts. We have multiple topology representations here - the physical transport topology and the abstracted Service Topology constructs.
"Nodes" and "Links" in our current discussions represent resource objects that exist in the physical transport topology. Both objects have physical characteristics (e.g. latency, a transfer function, bit error rates, etc.), and both have "Ports" (I/O interfaces) that move data streams into or out of each respective object.
The Physical topology model - model of theTransport Plane - consists of Nodes, Ports, Links, among other adaptation and topology constructs that are being defined by NML. EROs can be defined in terms of these objects and pathfinding over the transport topology can be done. IMHO, we do not need additional complexity, naming and addressing (the fallout of adding another concept) to appear in the transport plane topology. Can we all agree on this?
It makes sense (and reflects reality) to say that all Nodes and Links are in fact owned by one domain or another...no such thing really as a free Link. We should be able to represent this in our model. I think a "Point" construct - i.e. a Touch Point or Tangent Point does this rather nicely. (Admittedly, I had to be convinced myself that such a construct was useful and could work.)
What you bring up here is the interesting merger of policy with topology (as Freek also mentioned in his response). The existence of the ownership policy is external to the physical transport topology and does not need to be modeled within the transport topology. My conjecture is that this policy resides within the Service Plane. So, if we do have to discuss how to represent a joint policy-topology representation, it needs to exist within the Service Plane and the NSI group should do on top of how and what NML uses to define the transport plane topology. This will help NML get unstuck and move forward, AND come up with a comprehensive set of physical topology constructs that an NRM can use. Coming back to the point about "points" - it is clear that this concept has emerged due to the NEED to define an ownership attribute of a resource, since each resource is owned ONLY by a single NRM. One way to define an ownership attribute is to put this as an additional attribute of the resource object. This is consistent with current Service Plane where we use additional characteristics of the resource like latency, capacity, existing reservations schedule aka time etc. to implement the Path computation and scheduling function. The other way is to keep the concept of "points" in the service plane aka the "Service Termination Point" (STP). Service Termination Point can represent both the ownership aspects and can be mapped onto a Node/ Port on a Transport plane topology. In the service plane, a NSI request from the client would go from a source STP to a destination STP and over intermediate STPs, if so defined in the ERO. These STPs would define the inter-domain exchange points and would be mapped by the NRM onto a {Port-Link-Port} group that exists from a physical perspective to interconnect the two domains. To summarize my point of view: A. Lets separate the physical topology representations (NML) from the service topology abstractions (aka STP). B. Let us use the NML representations of the physical topology as a common layer for resource provisioning, path-finding (and even multi- layer pathfinding) on the physical plane. C. Let us look at the ownership policy aspects as an additional constraint along with capacity/time/scheduling set of constraints that apply to links and ports. D. Lets re-examine the need for Points, if necessary, within that Service Plane context. Inder (wearing non-chair hat) On Feb 22, 2010, at 3:52 AM, Jerry Sobieski wrote:
Hi all-
Here are some thoughts on why I think the notion of a "Point" does have merit in an NSI topology model:
"Nodes" and "Links" in our current discussions represent resource objects that exist in the physical transport topology. Both objects have physical characteristics (e.g. latency, a transfer function, bit error rates, etc.), and both have "Ports" (I/O interfaces) that move data streams into or out of each respective object. And, a resource could be a grouped and summarized object that hides a great deal of internal topology and/or performs a complex transfer function (more on this in a moment).
It makes sense (and reflects reality) to say that all Nodes and Links are in fact owned by one domain or another...no such thing really as a free Link. We should be able to represent this in our model. I think a "Point" construct - i.e. a Touch Point or Tangent Point does this rather nicely. (Admittedly, I had to be convinced myself that such a construct was useful and could work.)
So, given that two networks meet at such a point, how do we indicate that a Port from network A connects to a Link in network B?
A convenient way that has been explored in the literature is a derivative graph (sometimes called a Channel Graph): each physical component of the topology (i.e. the Nodes and Links) is reduced to a generalized "Resource" object with a corresponding set of Ports. For instance a Link becomes a Resource with one input Port and one output Port and some physical characteristic(s) e.g. latency. Ports are joined together through this notion of a "Point". A Point is a topological object that ties one or more Ports together indicating that they represent the same location topologically speaking (physically speaking, this might indicate that a fiber Link is plugged into a switch Node/Port interface)
In a sense, a Point has no physical characteristics besides the Ports that make up the Point. Resources ( physical Nodes and Links) have physical characteristics associated with them. But our Point construct simply ties a number of Ports together - the characteristics of that Point are wholly derived from the characteristics of the constituent Ports. A Point could in fact reference other Points as well as Ports - any/all such Points and their consituent Ports are all topologically equivalent.
In a practical sense, these Points could in fact be the Service Termination/Transit Points (STPs) we have alluded to in our discussions. (Even if we ultimately name them something else, the idea remains the same.) Further, the recognition of a Point object allows us to locate all Ports that are joined together (think of a broadcast domain). A Port construct would refer to a Point construct that would in turn refer to (list) all Ports that are joined at that Point. A Path can then be found by searching from Start Point to Port to Resource to Port to Point to Port to Resource to Port to Point to ... very clean...(IMO).
We can think of a Point as a topological construct that expresses purely connectivity (topological equivalence), where as a Link is a physical resource object or node in the physical network topology. This subtle and seemingly minor distinction keeps all of our physical constraints in the Resources and/or their Ports, and puts the topological structure in the Points. (It could be argued that this reduction actually means a Point should be called a link, but good grief...:-) In the Inter-Domain topology papers and standards, a "point" where two networks meet makes a certain amount of sense...).
Finally, a set of contiguous Resources could be grouped together into a larger object. This larger object could be another Resource object - thus creating a nesting of Resources to summarize and/or hide complexity. There needs to be a method of mapping internal Ports to the external Ports of such nested Resource objects - Points do this nicely without requiring internal Port references to leak out to external agents... These larger scale Resource objects could be refered to as "Network" objects if we chose - it does not change their structure or function, but indicates a relationship of the larger scoped object to the internal components. E.g. "A Network is a Resource object made up of other [sub-]Resources."
This modified NSI topology model may be implemented internally differently in various NSI implementations. Its not absolutely necessary that NSI use the NML topo model in its pristine form to describe our architecture. Nor is it necessarily the case that NML needs to make any changes to their model to accomodate NSI model. In fact, it is not it required that NSI implementations use either the NSI or NML topology internally in an implementation. NSI only needs to state the topology model it uses to describe the NSI architecture semantics and protocol - which does not place any requirements on implementers to build internal structures that must resemble this. How an implementation represents its topology internally is not our concern- the implementers just need to understand how they map NSI semantics to their implementation so that they express the same semantic value.
I think if we describe the NSI topology as a reduction of physical Nodes and Links to the their Resource state, then a topology of Resources, Ports, and tangent Points is (IMO) easily understood. I include a diagram of how all this can be diagramatically denoted...
Hope this helps... Jerry
Jeroen van der Ham wrote:
On 21/02/2010 18:20, John Vollbrecht wrote:
Attached is set of ppt slides to describe interdomain topology. I hope this helps - it is based on conversations in the NML group, and is my understanding of what the Glossary of terms that Guy is reviewing (and I think will review next Wed).
I just want to clarify my view of the conversation we have had in the NML group about this issue. This was mainly a discussion between myself and John wherein I tried to understand the NSI issue of describing inter-domain topologies.
The current NML topology model does not have "Points". Nor do we currently have plans to add them. *Unless* there is a use-case showing the need of Points, which clearly outlines why it is not possible to describe domain boundaries with the current NML Topology model. So far, I have not seen such a clear and valid use-case for "Points".
Jeroen. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
<Derived Graphs.pptx>_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
participants (12)
-
"Joan A. García-Espín" -
Cees de Laat -
Freek Dijkstra -
Gigi Karmous-Edwards -
Guy Roberts -
Inder Monga -
Jason Zurawski -
Jeroen van der Ham -
Jerry Sobieski -
John Vollbrecht -
Martin Swany -
Tomohiro Kudoh