Hi, the final proposal how the labels could look like is as follows (RNC format): Label = element nml:label { element nml:parameter { attribute name { "type" }& text }& ( element nml:parameter { attribute name { text }& text } + ) | anyElement+ } + ### taken from nmc base schema anyElement = element * {anyThing } anyAttribute = attribute * { text } anyThing = ( anyElement | anyAttribute | text )* an example: <nml:label> <nml:parameter name="type">c-vlan</nml:parameter> <nml:parameter name="value>42</nml:parameter> </nml:label> <nml:label> <nml:parameter name="type">wavelength</nml:parameter> <nml:parameter name="unit">nm</nml:parameter> <nml:parameter name="spacing">25GHz</nml:parameter> <nml:parameter name="value">1500</nml:parameter> </nml:label> By default, other nemaspaces than nml basic one are not needed but I would not forbid them. Use of a set of nml:parameter elements (flat structure) seems to be enough flexible to cover almost all possible cases but I can imagine a very rare requirement to have a nested structure inside nml:label, for example: <nml:label> <nml:paremeter name="type">xyz</nml:parameter> <nml-ext:something_1> <nml-ext:something_2> ... </nml-ext:something_2> </nml-ext:something_1> </nml:label> (that is why I've added anyElement in the RNC snippet) If you are 100% sure that such a requirement will not come up I'm fine to remove this extension possibility. Roman
On Labels: What we have defined are "resource labels", eg.: * Ethernet VLAN * Ethernet I-SID * Frequency on DWDM / Wavelength on CWDM * ATM VPC * ATM VPI * SONET/SDH STS3c/STM/AUG-1 timeslot * MPLS shim label perhaps even: * SSID on a wifi * strand in a fiber bundle * ... This label is used for both: * distinguishing between flows on a link (aka channels) * routing and switching (eg. "switch X will forward data from port 1, label 28 to port 4, label 42") So far so good. Now two issues. 1. On PortGroups: I assume that each Port is associated with a particular label. This is useful for monitoring, so we can distinguish between e.g. VLAN 120 and VLAN 42. For path finding, it seem useful to describe a all possible ports (e.g. "all VLANs that can dynamically created". For this, I propose to introduce a "PortGroup": which logically can be expanded to many individual Ports. The idea is still sketchy, but I like some input if this is a good approach. If so, I'll make a proposal. 2. On Destination Labels The "destination labels", such as destination IP address or destination MAC address are also used for routing and switching, just like the resource labels above. Hence I presumed that destination labels could be described the same way as resource labels. I'm longer sure that this is a good idea. Recall that each Port is associated with exactly one label. For a host with one IP address 2001:0DB8:B4C6:6AAE::1 this means that is has one ingress Port (for this IP address). On the other hand, it would have 2^128-1 egress Ports (for all possible IP addresses that is can send to). This discrepancy between ingress Port and egress Ports seems odd to me, and makes me doubt that destination labels are the same things as resource labels. As stated in my previous email, G.800 thinks it's a different beast: it associates resource labels with the adaptation, while is associates source- and destination labels with the termination. That's all nice, but I'm still at loss how to describe source- and destination labels in NML and how to deal with them. If you have any idea (good or bad), please share it. Freek
On May 9, 2012, at 5:37 PM, Freek Dijkstra wrote:
On Labels:
What we have defined are "resource labels", eg.: * Ethernet VLAN * Ethernet I-SID * Frequency on DWDM / Wavelength on CWDM * ATM VPC * ATM VPI * SONET/SDH STS3c/STM/AUG-1 timeslot * MPLS shim label perhaps even: * SSID on a wifi * strand in a fiber bundle * ...
This label is used for both: * distinguishing between flows on a link (aka channels) * routing and switching (eg. "switch X will forward data from port 1, label 28 to port 4, label 42")
So far so good. Now two issues.
1. On PortGroups:
I assume that each Port is associated with a particular label. This is useful for monitoring, so we can distinguish between e.g. VLAN 120 and VLAN 42.
For path finding, it seem useful to describe a all possible ports (e.g. "all VLANs that can dynamically created". For this, I propose to introduce a "PortGroup": which logically can be expanded to many individual Ports.
The idea is still sketchy, but I like some input if this is a good approach. If so, I'll make a proposal.
In the OSCARS world, we've done this, using the label terminology, as "the available labels on a port". Thus, a single port might have a variety of available labels that could be used on that port. That approach makes more sense to me than introducing a new grouping concept for ports that don't currently exist. Cheers, Aaron
2. On Destination Labels
The "destination labels", such as destination IP address or destination MAC address are also used for routing and switching, just like the resource labels above.
Hence I presumed that destination labels could be described the same way as resource labels. I'm longer sure that this is a good idea.
Recall that each Port is associated with exactly one label.
For a host with one IP address 2001:0DB8:B4C6:6AAE::1 this means that is has one ingress Port (for this IP address). On the other hand, it would have 2^128-1 egress Ports (for all possible IP addresses that is can send to).
This discrepancy between ingress Port and egress Ports seems odd to me, and makes me doubt that destination labels are the same things as resource labels.
As stated in my previous email, G.800 thinks it's a different beast: it associates resource labels with the adaptation, while is associates source- and destination labels with the termination.
That's all nice, but I'm still at loss how to describe source- and destination labels in NML and how to deal with them. If you have any idea (good or bad), please share it.
Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Internet2 Spring Member Meeting April 22-25, 2012 - Arlington, Virginia http://events.internet2.edu/2012/spring-mm/
Aaron Brown wrote:
For path finding, it seem useful to describe a all possible ports (e.g. "all VLANs that can dynamically created". For this, I propose to introduce a "PortGroup": which logically can be expanded to many individual Ports.
The idea is still sketchy, but I like some input if this is a good approach. If so, I'll make a proposal.
In the OSCARS world, we've done this, using the label terminology, as "the available labels on a port". Thus, a single port might have a variety of available labels that could be used on that port. That approach makes more sense to me than introducing a new grouping concept for ports that don't currently exist.
Explicitly calling it a PortGroup will make it easier to spot this for path finding ("hey, you can dynamically add new links here, just pick an available label!"). Another reason is that it allows easier distinction from a single Port with a dynamic label where you also like to describe the available labels (e.g. "this is a tunable laser; you can't add a new wavelength, but you can change the label to a different value"). Freek
I Have some comments I will just list: a.) How would you describe a flow space? If you are identifying VLANs and other virtual flow identifiers, we should consider how combinations of frame characteristics could identify a specific topological link (or "flow") Can we bind these to define a single flow identifier. This is obviously a question of how NML applies in OpenFLOW architectures...? b) A similar question for optical wave bands. Bands are variable width optical spectrum rather than fixed single wave ITU channels. They can be optically tuned and routed - effectively routing whole groups of waves. I don't know specifically how the bands are officially defined (continuous frequency ranges or discrete granularity). But there is hardware that support such wave bands today... c) Has there been any discussion about the use of the TPID field (ethertype) in the ethernet frame for topological link characterization purposes? A physical link may be hard wired to be 802.3 framed by merit of the interface. But the behaviour of the frames - and sometimes the format of those frames - is dependent upon the Ethertype field (TPID). For instance, many protocols have TPIDs reserved - IPv4, IPv6, ARP, tagged frames, doubly tagged frames, etc. The implication is that the physical 802.3 transport framing may carry *many* different types of streams which are differentiated by the TPID field. Our notions of single VLANs as connections really means TPID=8100 && VLAN=x. 802.1Q VLANs and PBB are simply particular subsets of possible wire framing. What is the abstract definition that NML uses to define a topologically significant link layer connection? As Freek alludes, [virtual] labels are part of the information that identify the topological link/connection/... d) The proposed notion of PortGroups sounds like it addresses an issue that NSI was sparring with - If an ingress/egress endpoint of a link or connection is identified by the topological n-tuple that uniquely identifies the characteristics of datagrams belonging to that "flow", then you have this issue of potentially thousands, or hundreds of thousands, of endpoints associated with each link - and different subsets of the n-tuple defining different groups or flows. IMO, looking at the n-tuple in the abstract, and defining Ports, or port groups, as formal terminal groupings of varous n-tuple permutations, has merit. So I think it is useful to work on this notion (!) e) Finally, With respect to Aaron's comments about Ports that don't exist (:-) (...I hope I understand the context properly...) - but they *do* actually exist. Just because they are virtual ports or virtual endpoints, or not yet assigned to a crossconnect does not make them immaterial or non-existent. I think this goes to a widespread gut sense that virtual ports makes topology DBs too big... I agree that this "feels" inelegant, but IMO this is not a scaling issue. I think we confuse a couple issues that makes us think it all becomes intractable or ineffiecient: first, managing large groups of [virtual] endpoints is a data base issue, and nothing we are thinking of exceeds present database capabalities to do this. Second, there are effieicent ways to optimize the management o these resources for sparse utilization or for high utilization. Third, is pathfinding - as we increase the degree of fan-out of our topological nodes, we get an exponential increase in the theoretical time to perform a PF search - if we use the same O(n^3)algorithms. So the theoretical complexity of the problem has not changed with increase endpoints, just our expected runtime increases. Fourth, if you define a zillion endpoints in your network, it is presumably because you think you may need them...right? And if you think there is a likelyhood that you will actually use them, then you still have the problem of managing them as they are allocated. So if they are potential for allocation, we have to manage them, so we still have the problem. Fifth, with the increase in degree of the virtual topological fanout, we have a problem of coherency - how do we communicate state changes of these endpoints to PFs in a global network who may want to consider using these endpoints? It begs the question of - does every PF need to know about every state change or every endpoint? If not, how would this work? These are hard issues, and frankly these are the issues that have caused previous attempts at connections oriented topology management and path finding to be deemed impractical. So making sure we understand how we intend to use the topology information is critical - and defining processes that properly implement those uses is far more important than worrying about the size of the topology DB. IMO. :-) Thanks! Jerry On 5/10/12 8:58 AM, Aaron Brown wrote:
On May 9, 2012, at 5:37 PM, Freek Dijkstra wrote:
On Labels:
What we have defined are "resource labels", eg.: * Ethernet VLAN * Ethernet I-SID * Frequency on DWDM / Wavelength on CWDM * ATM VPC * ATM VPI * SONET/SDH STS3c/STM/AUG-1 timeslot * MPLS shim label perhaps even: * SSID on a wifi * strand in a fiber bundle * ...
This label is used for both: * distinguishing between flows on a link (aka channels) * routing and switching (eg. "switch X will forward data from port 1, label 28 to port 4, label 42")
So far so good. Now two issues.
1. On PortGroups:
I assume that each Port is associated with a particular label. This is useful for monitoring, so we can distinguish between e.g. VLAN 120 and VLAN 42.
For path finding, it seem useful to describe a all possible ports (e.g. "all VLANs that can dynamically created". For this, I propose to introduce a "PortGroup": which logically can be expanded to many individual Ports.
The idea is still sketchy, but I like some input if this is a good approach. If so, I'll make a proposal.
In the OSCARS world, we've done this, using the label terminology, as "the available labels on a port". Thus, a single port might have a variety of available labels that could be used on that port. That approach makes more sense to me than introducing a new grouping concept for ports that don't currently exist.
Cheers, Aaron
2. On Destination Labels
The "destination labels", such as destination IP address or destination MAC address are also used for routing and switching, just like the resource labels above.
Hence I presumed that destination labels could be described the same way as resource labels. I'm longer sure that this is a good idea.
Recall that each Port is associated with exactly one label.
For a host with one IP address 2001:0DB8:B4C6:6AAE::1 this means that is has one ingress Port (for this IP address). On the other hand, it would have 2^128-1 egress Ports (for all possible IP addresses that is can send to).
This discrepancy between ingress Port and egress Ports seems odd to me, and makes me doubt that destination labels are the same things as resource labels.
As stated in my previous email, G.800 thinks it's a different beast: it associates resource labels with the adaptation, while is associates source- and destination labels with the termination.
That's all nice, but I'm still at loss how to describe source- and destination labels in NML and how to deal with them. If you have any idea (good or bad), please share it.
Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org <mailto:nml-wg@ogf.org> https://www.ogf.org/mailman/listinfo/nml-wg
Internet2 Spring Member Meeting April 22-25, 2012 - Arlington, Virginia http://events.internet2.edu/2012/spring-mm/
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Jerry Sobieski wrote:
a.) How would you describe a flow space? If you are identifying VLANs and other virtual flow identifiers, we should consider how combinations of frame characteristics could identify a specific topological link (or "flow") Can we bind these to define a single flow identifier. This is obviously a question of how NML applies in OpenFLOW architectures...?
For the theoretical background, please refer to section 7 of ITU-T G.800. [www.itu.int/rec/T-REC-G.800]. I have a preference to use existing terminology, even if that terminology is awkward at times. The question that this group should answer which of the existing concepts should be included in the NML schema, and how the elements of this schema relate to each other. A definition discussion might be better for a research group (such as GHPN-RG) than a work group such as NML. NML only defines "resource labels" so far, and does not define e.g. a "connectivity label", or "source label" or "destination label". The question at hand is if a "resource label" is sufficient for MAC and IP layer. I fear it is not. See the use case at https://forge.ogf.org/sf/go/artf6557. Your "flow identifier" seems the same as a G800 "connectivity label". If you think you have a distinct use case, please create a practical use case at https://forge.ogf.org/sf/go/projects.nml-wg/tracker.use_cases If you have a proposal how to add this to NML, please create a proposal at https://forge.ogf.org/sf/tracker/do/listArtifacts/projects.nml-wg/tracker.tr... Please note that a well documented use case still does not guarantee that NML will support it. For the best change of acceptance by the WG, it pays of to give an actual proposal, including UML schema changes/additions, XML example and RDF example. (I consider OpenFlow equal to MAC/IP in that it may look at source and destination labels beside resource labels. I consider it different from MAC/IP in that has a specific setup phase where the forwarding rules for a specific flow are added to the forwarding table. I leave it up to you what this means for a use case ;) )
b) A similar question for optical wave bands. Bands are variable width optical spectrum rather than fixed single wave ITU channels. They can be optically tuned and routed - effectively routing whole groups of waves. I don't know specifically how the bands are officially defined (continuous frequency ranges or discrete granularity). But there is hardware that support such wave bands today...
I know them as group muxes. That's one of 3 difficulaties in describing WDM labels. The other problems are: * CWDM describes a label as a wavelength (with 10nm) spacing, DWDM describes a label as a frequency. Should we allow translation between wavelenght and frequency? Should we describe CWDM and DWDM as incompatible technologies? * WDWM wavelengths can have multiple spacings (100GHz, 50 GHz, 25 GHz), and wavelengths of different spacing on the same fiber are somewhat common. How to describe this? For NML we opted to simply describe the properties, without adding the logic behind it (as e.g. NDL did in the past). See the recent proposal of Roman Łapacz. http://www.ogf.org/pipermail/nml-wg/2012-April/000941.html
c) Has there been any discussion about the use of the TPID field (ethertype) in the ethernet frame for topological link characterization purposes? A physical link may be hard wired to be 802.3 framed by merit of the interface. But the behaviour of the frames - and sometimes the format of those frames - is dependent upon the Ethertype field (TPID). For instance, many protocols have TPIDs reserved - IPv4, IPv6, ARP, tagged frames, doubly tagged frames, etc. The implication is that the physical 802.3 transport framing may carry *many* different types of streams which are differentiated by the TPID field. Our notions of single VLANs as connections really means TPID=8100 && VLAN=x. 802.1Q VLANs and PBB are simply particular subsets of possible wire framing. What is the abstract definition that NML uses to define a topologically significant link layer connection? As Freek alludes, [virtual] labels are part of the information that identify the topological link/connection/...
Adaptation with resource labels is the abstract model we use. You are correct that there is a shitload of potential labels which all can influence how a data flow is handled in a network. Not to mention all sort of stateful behaviour of network devices such as firewalls. The fine line is: - NML doesn't want to enforce a user to describe all labels. - NML wants to allow a user to describe the labels he/she cares about How to walk this fine line, we do not know yet (at least I don't). Perhaps NML will be flexible, allow aliases or shortcuts, while a specific application of NML, or a specific technology description may be rigid, and demand that a certain technology is described in this-and-that way. For example, the TPID is left out as a label, while the version number in the IP header is described as a label. Or neither is explicitly described (perhaps neither is relevant to either path finding or monitoring, so why describe them). This discussion may be more timely if we describe specific Ethernet examples. I welcome you to make a proposal. As always: https://forge.ogf.org/sf/go/projects.nml-wg/tracker.tracker_title
d) The proposed notion of PortGroups sounds like it addresses an issue that NSI was sparring with - If an ingress/egress endpoint of a link or connection is identified by the topological n-tuple that uniquely identifies the characteristics of datagrams belonging to that "flow", then you have this issue of potentially thousands, or hundreds of thousands, of endpoints associated with each link - and different subsets of the n-tuple defining different groups or flows. IMO, looking at the n-tuple in the abstract, and defining Ports, or port groups, as formal terminal groupings of various n-tuple permutations, has merit. So I think it is useful to work on this notion (!)
I think both Aaron and I agree on that. The only discussion we still have if we need a separate PortGroup concept, or can simply re-use the existing Port concept. My thinking is that a separate PortGroup (and perhaps also LinkGroup?) concept is required. Perhaps it's good to talk about this in a conf call.
e) Finally, With respect to Aaron's comments about Ports that don't exist (:-) (...I hope I understand the context properly...) - but they *do* actually exist.
I think Aaron "do not exist" remark was with respect to the introduction of the indeed-newly-introduced "PortGroup" NML object. Not referring to non-existing logical Ports in the real world.
Just because they are virtual ports or virtual endpoints, or not yet assigned to a crossconnect does not make them immaterial or non-existent. I think this goes to a widespread gut sense that virtual ports makes topology DBs too big... I agree that this "feels" inelegant, but IMO this is not a scaling issue. I think we confuse a couple issues that makes us think it all becomes intractable or inefficient: first, managing large groups of [virtual] endpoints is a data base issue, and nothing we are thinking of exceeds present database capabilities to do this. Second, there are efficient ways to optimize the management of these resources for sparse utilization or for high utilization. Third, is pathfinding - as we increase the degree of fan-out of our topological nodes, we get an exponential increase in the theoretical time to perform a PF search - if we use the same O(n^3)algorithms. So the theoretical complexity of the problem has not changed with increase endpoints, just our expected runtime increases. Fourth, if you define a zillion endpoints in your network, it is presumably because you think you may need them...right? And if you think there is a likelyhood that you will actually use them, then you still have the problem of managing them as they are allocated. So if they are potential for allocation, we have to manage them, so we still have the problem. Fifth, with the increase in degree of the virtual topological fanout, we have a problem of coherency - how do we communicate state changes of these endpoints to PFs in a global network who may want to consider using these endpoints? It begs the question of - does every PF need to know about every state change or every endpoint? If not, how would this work? These are hard issues, and frankly these are the issues that have caused previous attempts at connections oriented topology management and path finding to be deemed impractical. So making sure we understand how we intend to use the topology information is critical - and defining processes that properly implement those uses is far more important than worrying about the size of the topology DB. IMO. :-)
I think the rationale for looking into this problem is clear. I have a few comments on your above text (I do think it is a scaling issue), but for now will only say that you seem to make some assumptions about how a Port or PortGroups maps to a node in a path finding algorithm, and what type of algorithm is used for path finding. I think those assumptions are not necessarily true, and may obfuscate any discussion about path finding. If it is OK with you, I'll answer any subsequent mail discussing path finding off-list, as this was not the original thread of this topic. (I'm happy to continue the discussion, but suggest to do that off-list, and mail a summary to the NML list -- those who are interested in this discussion, please let us know, so we can cc you) Freek
participants (4)
-
Aaron Brown -
Freek Dijkstra -
Jerry Sobieski -
Roman Łapacz