draft-vasseur-mpls-computation-rsvp-02.txt

[sven.van_den_bosch@alcatel.be]

Hi,

I have been reiterating some inter-area traffic engineering work and I have
some questions regarding the above mentioned draft. The draft describes an
approach to allow the ingress to obtain a path from a path computation
server (PCS), possibly through relaying to message between different path
computation servers. This raises two questions:

1) resource reservation: Because the Path Computation Requests (PCR) may
need to be relayed between different Path Computation Servers (PCS), it is
possible that some time elapses between the selection of the path and the
actual setup. This can introduce race conditions in the path computation
process. In order to avoid these, it may be appropriate to optionally allow
the Path Computation Client (PCC) to ask for a reservation of the resources
while processing the PCR. When the PCS finds out that it is on the
requested path, it can continue the path setup which was already initiated.
When it isn't, reserved resources can be torn down with the reply message.
This can be achieved by:
- treating the PCR as an ordinary RSVP-TE Path message with additional
objects
- using Resv plus additional objects for a reply without resource
reservation teardown
- using ResvTear plus additional objects for a reply with resource
reservation teardown
This scenario may involve the need to send a path message from a PCS (ABR)
to more than one node. Then a problem arises with the REQUEST_ID because
intermediate nodes can not make the distinction between the path messages
(they have the same SESSION and SENDER_TEMPLATE objects). Two solutions are
feasible:
- use different LSP_IDs for every path message
- put a unique address of the PCS in the sender address
Some suggested modifications to the existing text for the last solution are
provided below

2) multi-stage computation: In a broader context (broader than pure
multi-area TE), PCSs may be used to compute sections of a path going over
different hierarchy levels in a network. Such levels may be introduced by
the use of FA-LSPs. Now, in this case, the specification of the complete
path may involve more than two PCS hops (as is typically the case with
multi-area TE because of the specifics of OSPF and ISIS hierarchy).
Guaranteeing the optimal path will then require the concatenation of
multiple LSP sections and the request for a very large number of path
computations. When setting up the paths at the same time, it can be shown
that the number of setup messages is linear with the number of edge nodes,
and this in each section.

Looking forward to discussion,
Sven.

Suggested text for the role of the PCC and PCS is given below

Path Computation Client (PCC)
1) The Path Computation Request (PCR) message is a Path message with
   - Tunnel_ID: unique identifier
   - Extended_Tunnel_ID: set to the ingress of the tunnel
   - egress address: egress tunnel address
   - sender address: set to an address belonging to the tunnel ingress
(maybe be same as Extended_Tunnel_ID if only one PCR
     is sent.
   - LSP_ID: unique identifier
   The PCC sends a request to one or more PCSs containing:
        a) already specified objects defined in [9] characterizing the
           request, and
        b) new objects defined in the present draft related
           to the request.
   The router alert option may be set in order to reserve resources during
the setup.
2) Upon receiving a positive reply to the PCR
        a) if a single path was requested, the one that is returned will
have been established
        b) if multiple paths were requested, select the desired one(s) and
initiate path setup
3) Upon receiving a negative reply to the PCR
        a) if multiple PCSs were contacted, wait for other replies
        b) else send new request to another PCS (can be suggested in
negative reply)

Path Computation Server (PCS)
1) Upon receiving a PCR
        a) Compute the desired path(s)
        b) If a single path was requested and the PCS is on the optimal
path towards the destination
           - continue path setup by sending Path message to destination
        c) If a single path was requested and the PCS is on the optimal
path towards one or more possible next PCS
           - continue the path setup
           - replace sender address with one of its own addresses and send
Path message to one or more next hop PCSs.
             Note that a different sender address must be chosen for each
other PCS.
        d) If multiple paths were requested and found, send a ResvTear
message containing positive reply (list of paths)
        e) If single path was requested and not found, send a ResvTear
message containing negative reply and possibly a
           suggestion for other PCS

2) Upon receiving a positive reply to the PCR
        a) if a single path was requested, the one that is returned will
have been established
        b) if multiple paths were requested, select the desired one(s),
concatenate and send to PCC

3) Upon receiving a negative reply to the PCR
        a) if multiple PCSs were contacted, wait for other replies
        b) else send new request to another PCS (can be suggested in
negative reply)
        c) if all PCSs give negative reply, send negative reply to PCC