The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Multi-LSP Notify in GMPLS
Adrian, I was wondering why do we need the <sender descriptor> in the GMPLS Notify message ? My understanding is that the Notify message is meant to notify upstream nodes about certain events such as FIS, FRS without tearing down the LSPs. It would be reasonable for the Notify message to have the ResvTear like format (with FILTERSPEC list), because it will better suit the protection/restoration schemes especially for the MPT LSPs. Would it be better to have instead of <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>] this <Notify message> ::= <Common Header> [<INTEGRITY>] <MESSAGE_ID> <ERROR_SPEC> <notified session> <notified session> ::= <SESSION> <RSVP_HOP> <STYLE> <flow descriptor list> [<notified session>] ? ________________________ Igor Bryskin Chief Architect of IP Software, VIRATA Corporation, 65 Boston Post Road, suite 106, Marlborough, MA, USA, Tel: (508)-786-1920, ext. 103 -----Original Message----- From: Adrian Farrel [mailto:AF@dataconnection.com] Sent: Wednesday, September 27, 2000 5:40 PM To: mpls@UU.NET Cc: 'Lou Berger'; Kireeti Kompella (E-mail); Yakov Rekhter (E-mail); Ayan Banerjee; Jonathan Lang; jdrake@calient.net; Peter Ashwood-Smith Subject: Multi-LSP Notify in GMPLS 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 |
|