Here is some info on STP use and specification... Jerry -------- Original Message -------- Subject: STPs Date: Tue, 28 Aug 2012 15:51:22 -0400 From: Jerry Sobieski <jerry@nordu.net> Organization: NORDUnet To: Inder Monga <imonga@es.net> Hi Inder- Rereading the STP info I sent you and I think we (you and I) should step through this whole process in detail. I've tried to simplify below - and added how I think this should work. What do we have for STPs from NSI v1?, and what do we need regarding STPs for v2? Fron NSI v1, we have defined "Service Termination Points" to be generic topological locations where an NSI service can terminate or orignate a Connection. We place no physical requirements on STPs as part of the NSI specification. In v1, we define STP _/Identifiers/_ to be 2-tuples comprised of a network component and a local id component. This works well in that it requires that each NSA to translate the STP Identifier into local provisioning processes without requiring the local NSA relinquish or expose internal detail. In v1 STPs have the following short comings: In v1 we have no compact means of enumerating STPs. I.e. if, for instance, a NSI service delivers VLAN tagged ethernet connections, then each VLAN requires a specific STP be defined. This is necessary in order to define SDP pairs. While this is not a scaling issue, it does make topology descriptions large and difficult for human management. We need a compact form of describing, for instance, 4000 vlans on a port as STPs. In v1 we also have the "exhaustive search" problem. This is actually a problem with Reservation Requests in that the ResvReq primitive only allows a single STP be used as a SourceSTP or DestSTP for the request. And likewise transit points are similarly constraint to a single STP. This forces the RA to do an exhaustive search of the STPs trying each one until it suceeds - slow and inefficient in large virtual STP spaces. The ResvReq primitive needs to be able to handle a SourceSTP or DestSTP specification that evaluates to a _/set of STPs/_ that are valid useable terminals - for instance "any available VLAN on a particular port". This requires the STP references used in the SourceSTP and DestSTP and ERO STP fields to be more expressive to define groups of STPs instead of a single terminal point. In v2, we want to allow the RA to specify a group of allowable STPs and let the PA choose one of that group that works and return the choice in the confirmation. The solution proposed below is an "STP Reference" that uses Type-Value pairs to define a set of STPs. This is exactly what we decided at Baton Rouge. This proposed solution maintains the current STP 2-tuple Identifier and handling, and adds new capability that allows physical topology specification where such information is available or known. This will also allow "labels" to be used if a network or service definition wishes to define and use them. The proposed solution is syntactically simple as all references can be specified and parsed as type-value pairs with simple compact expression syntax to enumerate the sets. - An STP /**reference**/ describes a _/set/_ of STPs. The reference may evaluate to a single STP, or none, or a group of STPs. How that STP Reference is used semantically is context sensitive. - There are three basic ways we can form an STP /reference/: 1) Using the current 2-tuple STP Identifier: <networkid="foo"><localid="bar"> 2) Using the physical n-tuple topological elements that locate the STP: <topology="urn:ogf:network:Aruba..."><switch="sw1">...<port="ge3-2"><outertag=1000><innertag=9> 3) Using a combination of single 2-tuple STP Identifier and some number of n-tuples. <networkid="northernlight"><localid="CPH-transitnode"><vlan=100,101,102> - The 2-tuple STP /Identifier/ is a symbolic name for an STP. Thus that name must correspond to some physical topological location inside a network. I.e. there must be a mapping from the STP Identifier to the local physical topology. However, this mapping is a local intra-domain issue. Thus, what that STP Identifier maps to locally is not required or guaranteed to be defined using NML or any other particular topological structure, nor is the mappng required to be publicly announced. It is solely up to the local NSA to translate an "STP Identifier" to "local topological information". This allows the intra-domain topology to remain private. It does /not/ require that the intra-domain topology detail be hidden, but allows it. Further, the STP Identifier itself does not need to be advertised at all in order for NSI CS protocol to work - if an RA sends a request with an STP Identifier to a PA, as long as the "networkid" type/value can be extracted from the 2-tuple STP Identifier, and that network can be found within the global inter-domain topology, then the protocol will function properly. - A "n-tuple" reference is a sequence of topological constraints that identify a set of STPs. These topological constraints are formulated as _/Type-Value Pairs/_. The "type" is a string corresponding to a topological object type, the "value" is an expression that identifies particular instances of the topological object type. For instance, if type is "switch" and the value is "ethx1" then we are refering to an object typed as a switch and identified as ethx1. In NSI, an n-tuple STP reference will use NML types, and begins with a "topology" TV pair. The topology tuple idenitifies the top level grouping of topology information. Examples: *n-tuple ex1:* [ <topo.="urn:ogf:network:aruba:2000"><switch="sx1"><port="ge3-0"> ] This describes a single STP: port ge3-0 on a switch sx1 in the aruba network topology. *n-tuple ex2:* [ <topo="aruba"><switch=sx1><port=ge3-0><vlan=100,101,102> ] This describes a set of three STPs, ordered as appearing in the vlan tuple. A fully expanded equivalent reference would be: [ <topo="aruba"><switch=sx1><port=ge3-0><vlan=100>, <topo="aruba"><switch=sx1><port=ge3-0><vlan=101>, <topo="aruba"><switch=sx1><port=ge3-0><vlan=102> ] *n-tuple ex3:* <topo="aruba"><switch=sx1><port=ge3-0, ge3-2,ge4-0><vlan=1000..1999> This describes 4000 STPs. The expanded list order would be: [ <topo="aruba"><switch=sx1><port=ge3-0><vlan=1000>, <topo="aruba"><switch=sx1><port=ge3-0><vlan=1001>, ... <topo="aruba"><switch=sx1><port=ge3-0><vlan=1999>, <topo="aruba"><switch=sx1><port=ge3-2><vlan=1000>, <topo="aruba"><switch=sx1><port=ge3-2><vlan=1001>, ... <topo="aruba"><switch=sx1><port=ge3-2><vlan=1999>, <topo="aruba"><switch=sx1><port=ge4-0><vlan=1000>, <topo="aruba"><switch=sx1><port=ge4-0><vlan=1001>, ... <topo="aruba"><switch=sx1><port=ge4-0><vlan=1999> ] n-tuple ex4: <topo="aruba"><switch=sx1><port=ge3-0><vlan=*> This indicates that STP consisting of port and vlan tag, but any vlan tag is viable. (An equivalent specification would be to say <vlan=0..4095> - An STP reference generates an *ordered* set of STPs. Thus in describing *SDPs*, we can use two STP references to indicate the matching pairs - elements are paired in order corresponding. SDP Ex1: <topo=aruba><switch=sx1><port=ge3-0> == <topo=bonaire><switch=eth1><port=ge2-0-0> This equates two ports as peering a single SDP. SDP Ex2: <topo=aruba><switch=sx1><port=ge3-0><vlan=1..100> == <topo=bonaire><switch=eth1><port=ge2-0-0><vlan=1..100> This equates vlans 1 to 100 on their repsective ports. SDP Ex3: <topo=aruba><switch=sx1><port=ge3-0><vlan=1000..1499> == <topo=bonaire><switch=eth1><port=ge2-0-0><vlan=2100..2599> This equates vlans 1000 thru 1499 at Aruba's edge to vlans 2100 thru 2599 at Bonaire's edge. (This would be typical of some hidden intervening network elements that were translating VLANs...say a SONET bridge or metro ethernet service...) How I see this working: - A Reservation Request contains STP References for the SourceSTP, DestSTP and any ERO STPs. The Reservation Request context interprets each reference to mean that "Any one STP from the referenced set can be used as the terminal". So for example, given the following path issued from an RA to a PA in a ResvReq for a bidirectional connection: SourceSTP := <topology=urn:ogf:network:Aruba.ets:2000><switch=ashb1><port=ge0-0><vlan=100> ERO(1) := <neworkid=northernlight><locaid=CPH> ERO(2) := <networkid=starlight><localid=ams> DestSTP := <topology=urn:ogf:network:Curacao.ets:2000><switch=clpk-prime><port=ge1-1><vlan=*> The SourceSTP is an n-tuple reference. The pathfinder is constrained to begin the path from port ge0-0 vlan 100 on a switch called ashb1 (ashburn 1) in the Aruba system. Presumably this is a bidirectional port since the request wants a bidirectional connection. We will further simplify the example by asserting that the Source and Destination STPs are not part of any SDP - i.e. they are conventional user end points on the edge of their networks. The first transit point is northernlight:CPH. So the intermediate PA NSA (iPA) processing the uRA request examines the Source and ERO(1) STP references and extracts the networkids. Since the Source contains the "topology" Type-Value pair, it is interpretted as a physical n-tuple reference form, and the "topology" TV pair indicates the network within which the STP resides. Similarly, the ERO(1) reference has a "networkid" Type-Value pair indicating it is an STP Identifier (2-tuple) form. The NSA then constructs an inter-domain path tree from the Aruba network to the northernlight network. This path tree is culled by other constraints (e.g. available bandwidth). When all constraints have been met, the PF chooses an arbitrary single path from the remaining paths in the tree and proceeds to reserve it. If it fails, we mark that path accordingly and try the next path in the tree. (Note: this segment reservation process can use similar TV pair references to indicate groups of STPs, so this transit segment reservation process is not using an exhaustive hunt for a viable STP.) When the segment reservation is confirmed, then we retain the rest of the path tree (as we may need it later) and move on to process the next transit segment. It is important to note that the northernlight:CPH STP Identifier does not communicate any physical characteristics to the external agents. I.e. it may have been learned from some out of band method, or it may have been announced but with no physical mapping details associated. For purposes of this example showing how TV pairs and STPs work, we will assert that the northerlight:CPH identifier maps internally to <topology=urn:ogf:network:nordunet:2000><switch=juniper1><port=*><vlan=2000..4095>. However, this internal mapping is not announced publicly, only the STP Identifier is announced and perhaps a location. Since the "port" and "vlan" TV pairs are only partially resolved in this n-tuple, any Reservation using the CPH STP will need to resolve the port and vlan components. In this example, the RA does not know that CPH is only a partially resolved STP. However, the NSA responsible for northernlight will recognize this and will select a port and vlan to be used on the switch "juniper1" and add these to the reference to fully resolve the terminus. For example, the northernlight NSA examines its internal topology and selects port te3-0 and vlan 2345. The expression generated by the uPA might look as such: <networkid=northernlight><localid=CPH><port=te3-0><vlan=2345> Thus the n-tuple for the fully resolved transit point will be <topo=urn:ogf:network:northernlight:2000><switch=juniper1><port=te3-0><vlan=2345>. Since the "CPH" end point specified by the uRA and iRA is not fully resolved, the northernlight uPA cannot return that same unresolved STP Identifier in the "as-built" confirmation info. But similarly, since the associated n-tuple topology was private (i.e. the announced topology did not include CPH details), we do not want to return the full n-tuple as this would expose internal private information (a security hole). So the northernlight NSA dynamically generate a "localid" for the fully resolved terminus and inserts this localid into its local STP Identifier table along with the n-tuple mapping. It returns this dynamic localid in the "as-built" results to the RA. So, for this example, the northernlight NSA would generate an arbitrary localid, say "CPH0a1e", and return <networkid=northernlight><localid=CPH0a1e">. It is important that this fully resolved STP Identifier be returned - as it will be used as the SourceSTP for the next transit segment by the RA. So it is important that the RA extract the _/as-built/_ information for one segment when constructing the next transit segment and does not simply use the transit STP referenced originally from the uRA. A dynamic localid must exist in the local translation table as long as all connections or processes utilizing or referencing that STP Identifier are alive. The NSA PF sees another transit point ERO(2): starlight:ams. "ams" is also partially resolved STP Identifier that maps to: <topo=urn:...:starlight:...><switch=f10a><port=te4-0-0><vlan=1000..2000>. And like CPH, the detailed topology for ams is not announced. However, ams is SDP'd with a similar partially resolved STP "netherlight:chi". So, the SDP could be announced in one of several ways: First, both netherlight and starlight could simply announce the partial STP Identifiers, ala: <networkid=starlight><localid=ams> == <networkid=netherlight><localid=chi>. Each of the STP Identifires evaluate to an ordered set of STPs, and these are paired correspondingly. Alternatiely, the n-tuple expressions for both ams and chi could be announced and the respective n-tuples used in the SDP expression: <topo=urn:...:starlight:...><switch=f10a><port=te4-0-0><vlan=1000..2000> == <topo=urn:...:netherlight:...><switch=hdx2><port="p2-0"><vlan=1000..2000> Note: Even though the n-tuple is announced for the peering points, there is no explicit association made betwen these n-tuple STP reference and any particular STP Identifier. Thus The process continues for each segment defined via EROs and terminates at the Bonaire STP descibed by the n-tuple reference in the DestSTP. THis reference stipulates a vlan=* tuple, implying the any available vlan is ok. If we assume that Bonaire advertised this n-tuple publicly, then we return the n-tuple in as-built information. If the endpoint was not advertised, we return a dynamic STP Identifier or reject the request - depending upon local policy. Please note that this proposal is dealing with Type Value pairs and expressions involving those TV pairs. The lexical form of the TV pairs is open for discussion - we could use the bracketted form as in the above examples, or some other form that preserves the enumeration and logical interpretation expressed in the proposal and examples. Also note that this proposal is not sensitive to URNs. The n-tuple forms use URNs simply because these examples assumed NML as the underlying topology representation. So URNs can be used where named objects are referenced - or not. It is assumed the "networkid" type would map to a NML "topology" object though a standard lexical transform. Thoughts? Jerry