The MPLS WG Archive

[Adrian Farrel <AF@dataconnection.com>]

Lou, Peter, et al.

I have been talking with John Drake, Jonathan Lang, Ayan Banerjee and
(briefly) Yakov Rekhter about whether it is correct to apply bundling to the
Notify message or whether there are other optimizations that can be made.

The case we were considering involved the failure of a single link or node
that impacted very many LSPs where potentially large numbers need to be
notified to the same target.  The current version of the draft requires that
a single Notify message is built for each failed LSP, but allows these to be
bundled together for dispatch to a common target.

Building on the Summary Refresh construct in
draft-ietf-rsvp-refresh-reduction, I am proposing a solution where a single
Notify carries information about more than one failed LSP.  The restrictions
are
- all LSPs reported on one Notify must be for the same Notify target
- the same error spec must apply to all LSPs reported on the same Notify

Using this approach there is a saving of at least 40% in line usage compared
with bundling.  There are also definite advantages in terms of buffer usage
in a normal implementation.

Note that none of this predicates against "Non-Adjacent Message Bundling"
which could still be used with this form of Notify message.

I have taken the liberty of redrafting section 5 of the draft and tidying
some of the wording as I went along.  I would welcome your comments.

Regards,
Adrian


5. Notification

   This section defines a signaling extension, the Notify message, that
   enables expedited notification of failures and other events to nodes
   responsible for restoring failed LSPs.  This extension is RSVP
   specific although similar extensions could be defined for CR-LDP.


5.1. Notify Message

   The Notify message provides a mechanism to inform non-adjacent nodes
   of LSP related events.  This message differs from the currently
   defined error messages (i.e., PathErr and ResvErr messages of RSVP)
   in that it can be "targeted" to a node other than the immediate
   upstream or downstream neighbor and that it is a generalized
   notification mechanism.  In particular, the Notify message does not
   need to follow the hop-by-hop route of the Path since this may be
   inappropriate in cases of link failure.

   The Notify message does not replace existing error messages, but may
   initially be sent instead of existing error messages where the intent
   is that the Notify recipient should take remedial action before the
   network has recourse to the normal error processing.

   The Notify message is sent addressed to the target node without the
   router alert option (see 5.1.1).  This means that at transit nodes
   the IP packet may be forwarded by IP without being passed to the
   RSVP protocol code.  If a Notify is passed to the RSVP protocol code
   on a node which is not the destination of the Notify message, that
   node MUST forward the message, unmodified, towards the target.
   If it is known or suspected that the transit nodes will unnecessarily
   intercept Notify messages, they MAY be sent encapsulated in a second
   IP header.

   A Notify message may inform the destination of the an event on
   multiple LSPs.  This is achieved using a technique similar to the
   Summary Refresh in [RSVP-RR].

   To support reliable delivery of the Notify message, an Ack Message
   [RSVP-RR] is used to acknowledge the receipt of a Notify Message.  A
   node that receives the a Notify message MUST send an Ack message
   confirming receipt of the Notify message.

   Note: for CR-LDP there is not currently a similar mechanism. In CR-
   LDP, when a failure is detected it will be propagated with
   RELEASE/WITHDRAW messages radially outward from the point of failure.
   Resources are to be released in this phase and actual resource
   information is fed back to the source using the feedback mechanisms
   of [FEEDBACK].  In this manner the source will have an accurate view
   of available resources and can start rerouting much sooner.


5.1.1. Required Information

   The Notify message is a generalized notification message.  The IP
   destination address is set to the IP address of the intended
   receiver.  The Notify message is sent without the router alert
   option.


   <Notify message> ::= <Common Header> [<INTEGRITY>] <MESSAGE_ID>
                        <ERROR_SPEC> <notified session>

   <notified session> ::= <SESSION> [<sender descriptor>]
                          [<notified session>]

   <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
                           [<ADSPEC>] [<RECORD ROUTE>]


   The INTEGRITY object would normally be omitted since it provides hop-
   by-hop validation which is not appropriate for a multi-hop message.
   Compare with the ResvConf message which must be processed at each hop
   along its path.

   The MESSAGE_ID object is mandatory. All LSRs implementing support for
   Notify messages must also include support for this object and the
   Ack message.  The MESSAGE_ID object is defined in [RSVP-RR].

   The ERROR_SPEC object specifies the error and includes the IP address
   of either the node that detected the error or the link that has
   failed.  The error reported applies equally to all LSPs reported on
   the same Notify message.  See ERROR_SPEC definition in RFC2205.


--
Adrian Farrel  mailto:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422