[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RS-DT Wrap-Up Statements
Dimitri,
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?
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;
b) necessary binding (neighbor linkID=> neighbor signaling address, neighbor
nodeID=> neighbor signaling address) is provided via LMP
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.
>
>
>
>
>
>
>
>