folks -
The initial evaluation phase of existing routing protocols required
definition of a common pattern. The definition of this pattern last
until beginning of november (input from several parties) now that pieces
are in place needs to move a step further.
The evaluation document will be issued by end-november to close this
first phase. The content of this document will be articulated around the
below terminology, scenarios and features.
1. Terminology:
--------------
- Pi is a physical node (bearer/data/transport plane) node
- Li is a logical control plane identifier that is associated to a
single data plane (abstract) node
Li = logical node id or "TE router id" i.e. for
. RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA
. RFC 3784: Traffic Engineering Router ID TLV (Type 134)
- Ri is a control plane "router" e.g. (advertising) Router_ID i.e.
. RFC 2328: Router ID (32-bit)
. RFC 1195: IS-IS System ID (48-bit)
Note: in the below Figure 1.
- R3 represents an LSR with all components collocated.
- R2 shows how the "router" component may be disjoint from the node
- R1 shows how a single "router" may manage multiple nodes
The Router_ID (represented by Ri) does not enter into the identification
of the logical entities representing the data plane resources such as
links. The Routing DataBase (RDB) is associated to the Ri.
Note: the "signaling controller" i.e. the control plane entity that
processes the signaling messages (referred to as Si) is not represented
in these Figures. Multiple signalling controllers can be associated to
one Ri and make use of the path computation function associated to the Ri.
2. Mechanisms:
-------------
Focus is on routing information exchange between Ri entities (through
routing adjacencies) within single hierarchical level. Routing
information mapping between levels may require specific guidelines.
The control plane does not transport Pi information as these are data
plane addresses for which the the Li/Pi mapping is kept (link) local -
see for instance the transport LMP document where such exchange is
described. Example: the transport plane identifier is the Pi (the
identifier assigned to the physical element) be for instance
"666B.F999.AF10.222C", the control plane identifier is the Li (the
identifier assigned by the control plane), be for instance "1.1.1.1".
The control plane exchanges the control plane identifier information but
not the transport plane identifier information (i.e. not
"666B.F999.AF10.222C" but only "1.1.1.1"), The mapping Li/Pi is kept
local. So, when the Si receives a control plane message requesting the
use of "1.1.1.1", Si knows locally that this information refers to the
data plane entity identified by the transport plane identifier
"666B.F999.AF10.222C".
The control plane carries:
1) its view of the data plane link end-points and other link connection
end-points - note: advertisement of reachability can be achieved using
the techniques described in
<http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-01.txt>
2) the identifiers scoped by the Li's i.e. we speak about an associated
IPv4/IPv6 addressing space;
Evalution Scenarios:
-------------------
The scenarios are the following: resp. case 1), 2) and 3)
------------------- ------
|R1 | |R2 |
| | | | ------
| L1 L2 L3 | | L4 | |R3 |
| : : : | | : | | |
| : : : | | : | | L5 |
Control ---+-----+-----+--- ---+--- | : |
Plane : : : : | : |
----------------+-----+-----+-----------+-------+---+--+-
Data : : : : | : |
Plane -- : -- -- | -- |
----|P1|--------|P3|--------|P4|------+-|P5|-+-
-- \ : / -- -- | -- |
\ -- / | |
|P2| ------
--
case 1) as represented either direct links between edges or "logical
links" as per below figure (or any combination of them)
------ ------
| | | |
| L1 | | L2 |
| : | | : |
| : R1| | : R2|
Control Plane --+--- --+---
Elements : :
------------------+-----------------------------+------------------
Data Plane : :
Elements : :
----+-----------------------------+-----
| : : |
| --- --- --- |
| | |----------| P |----------| | |
---+--| | --- | |---+---
| | | | | |
| | P1|-------------------------| P2| |
| --- --- |
----------------------------------------
Another case is constituted by the Abstract Node as represented in the
below figure. There is no internal structure associated to the abstract
node.
--------------
|R4 |
| |
| L6 |
| : |
| ...... |
---:------:---
Control Plane : :
+------+------+------+
Data Plane : :
---:------:---
|P8 : : |
| -- -- |
--+-|P |----|P |-+--
| -- -- |
--------------
Note: base scenarios (being not combinations or decomposition of
entities) can further complete this set
4. Specific Considerations
-----------------------
Representation of bandwidth requires further analysis i.e. GMPLS Routing
defines an Interface Switching Capability Descriptor (ISCD) that
delivers information about the (maximum/minimum) bandwidth per priority
an LSP can make use of. In the ASON context, other representations are
possible, e.g. in terms of a set of tuples <signal_type; number of
unallocated timeslots>. The latter also may require definition of
additional signal types (from those defined in RFC 3496) to represent
contiguous concatenation i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64,