[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RS-DT Wrap-Up Statements
dimitri, see in-line
----- Original Message -----
From: "dimitri papadimitriou" <dpapadimitriou@psg.com>
To: "Igor Bryskin" <ibryskin@movaz.com>
Cc: <dimitri.papadimitriou@alcatel.be>; <ccamp@ops.ietf.org>
Sent: Wednesday, November 24, 2004 11:02 AM
Subject: Re: RS-DT Wrap-Up Statements
> igor - see in-line:
>
> Igor Bryskin wrote:
>
> > 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?
>
> 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.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> > .
> >
>