Subject: RS-DT Wrap-Up Statements

From: dimitri papadimitriou <[email-masked]>
Date: Wed, 24 Nov 2004 10:25:20 +0100

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.

---

From: "Igor Bryskin" <[email-masked]>
Date: Wed, 24 Nov 2004 10:37:32 -0500

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

---

From: dimitri papadimitriou <[email-masked]>
Date: Wed, 24 Nov 2004 17:02:53 +0100

igor - see in-line:

> with each of the latter having a dedicated signaling controller for TE

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)

> 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

> 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

hope this clarifies,
- thanks.

>>contiguous concatenation i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64,
> 
> 256.
> 
> .

---

From: "Igor Bryskin" <[email-masked]>
Date: Wed, 24 Nov 2004 11:29:26 -0500

dimitri, see in-line

----- Original Message ----- 
From: "dimitri papadimitriou" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 24, 2004 11:02 AM
Subject: Re: RS-DT Wrap-Up Statements

> 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.

> required that falls beyond the scope of routing and that could be

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

---

From: dimitri papadimitriou <[email-masked]>
Date: Wed, 24 Nov 2004 19:32:08 +0100

igor,

> the help of PCE(s) could compute and signal TE paths for them.

there is a difference between functionally separate Si from Ri and 
physically separate the RDB from the path computation function (i am not 
covering the latter - per scope of the document) - the document covers 
routing information exchange between Ri (over routing adjacencies)

>>>Also, how in your opinion a signaling controller knows which address to
> 
> send
> 
>>>b) necessary binding (neighbor linkID=> neighbor signaling address,
> 
> neighbor
> 

example: if you take gmpls-overlay that mentions "An edge-node is 
identified by either a single IP address representing its Node-ID, or by 
one or more numbered TE links that connect the edge-node to the core- 
nodes." there is nothing specifically different here compared to this 
approach

>>>>one Ri and make use of the path computation function associated to the
> 
> Ri.
> 
>>>>2. Mechanisms:
>>>>-------------
>>>>