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(a)nordu.net>
Organization: NORDUnet
To: Inder Monga <imonga(a)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
