igor,
Do you think it is reasonable/practical to separate routing controller
from signaling controller and consider scenarios such as a single routing
controller manages (provides advertisements) for several transport nodes
with each of the latter having a dedicated signaling controller for TE
tunnel provisioning?
this is a "functional" separation - in the basic association Si <-> Ri <-> i, we retrieve the canonical LSR (note i will change the word "can" by "may" in the below informational statement)
IB>> Separation could be physical, not just functional. Consider, for instance, a transport network built of WXCs that do not have own control plane. In this case a routing controller managing one or several such WXCs could advertise their resources, while separate signaling controllers with the help of PCE(s) could compute and signal TE paths for them.
Also, how in your opinion a signaling controller knows which address to
send
Path message for the next hop along the path. Possible options: a) ID of a numbered link is routable or RouterID in unnumbered ERO sub-object (which is transport node ID) is routable;
several points here: 1. we refer to a "TE Router_ID" per RFC 3477 recommendation 2. we should indicate these "identifiers" are TE reachable in the scope of the covered application 3. even if relevant the scope of this is related to routing
b) necessary binding (neighbor linkID=> neighbor signaling address,
neighbor
nodeID=> neighbor signaling address) is provided via LMP
in the case of multiple association an additional information is required that falls beyond the scope of routing and that could be achieved using LMP
IB>> Personally, I don't like the assumption that transport node IDs and linkIDs of numbered links are routable (especially in the context of non-PSC networks) and prefer relying on LMP or some other neighbor auto--discovery mechanism.
Igor
hope this clarifies, - thanks.
Thanks, Igor
----- Original Message ----- From: "dimitri papadimitriou" <dpapadimitriou@psg.com>
To: <ccamp@ops.ietf.org>
Sent: Wednesday, November 24, 2004 4:25 AM
Subject: RS-DT Wrap-Up Statements
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,
256.
The GMPLS routing method proposed in GMPLS Routing is the most straightforward without requiring any bandwidth accounting change from an LSR perspective. However, it introduces some lost of information. This lost of information affects the number of signals that can be used but not the range they cover. On the other hand, if additional technology specific information (such as capabilities) are advertised a finer grained resource countdown and accounting can be performed allowing for network wide resource allocation in Sonet/SDH environments.
.
.