-------- Original Message --------
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