1 / 9

Protection & Restoration Design Team - CCAMP WG IETF 56 - San Francisco March’03

RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt. Protection & Restoration Design Team - CCAMP WG IETF 56 - San Francisco March’03. Effort Positioning, Status and Timing … we make some progress ;-). Terminology.

powa
Download Presentation

Protection & Restoration Design Team - CCAMP WG IETF 56 - San Francisco March’03

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RSVP-TE Extensions in support of End-to-End GMPLS-based Recoverydraft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt Protection & Restoration Design Team - CCAMP WG IETF 56 - San Francisco March’03

  2. Effort Positioning, Status and Timing … we make some progress ;-) Terminology draft-ietf-ccamp-gmpls-recovery-terminology-01.txt March’02 March’02 (closed) ~ PS or Info (?) for July’03 Analysis draft-ietf-ccamp-gmpls-recovery-analysis-03.txt April’02 Jan’03 (closed) ~ Info for June’03 Functional Specification draft-ietf-ccamp-gmpls-recovery-functional-01.txt July’02 Jan’03 (closed) ~ PS for April’03 Aug’02 GMPLS Protocol Specification draft-lang-ccamp-gmpls-recovery-e2e-signalling-00 Feb’03 (closed) ~ PS for July’03

  3. Thanks… Deborah Brungard Sudheer Dharanikota (sudheer@ieee.org) Jonathan Lang (jplang@ieee.org) Guangzhi Li Eric Mannie (eric_mannie@hotmail.com) Dimitri Papadimitriou (dpapadimitriou@psg.com) Bala Rajagopalan Yakov Rekhter

  4. After 1+ year some feelings… • Terminology starts to be widely adopted… • Now that we’ve start last step on signalling, new bunch of “requirement” I-d’s (note: we never took “requirement phrasing” in the P&R I-d’s) with two scopes: • either requirements summaries (any specific need ?) • or extended/uncovered approaches (>< P&R scope is definition of one common baseline … not yet a universal GMPLS-based recovery protocol) => current expectations are more on consolidation ! • >< analysis I-d has shown to be still too largely scoped (to be nailed down) • More “philosophical” still too much defensive (affiliation-based) approaches… but we are under recovery phase ;-)

  5. Basic mechanisms • Recovery Scope: end-2-end • Coverage: • Protection: full LSP signalling (cross-connection) • Pre-planned Re-routing: pre-signalling (b/f) + LSP activation (after failure occurrence) • Dynamic Re-routing (Restoration): full LSP signalling (after failure occurrence) • Notification message (and objects) <= from RFC 3473 • Two objects described: • (Extended) Protection Object <= inspired from RFC 3473 • Primary Path Route Object - PPRO for disjointness in shared mesh

  6. To be covered… • Bulk LSP recovery • note: bulk notification is covered from RFC 3473 + flooding reduction-based notification vs “controlled” flooding … not sure all outcomes have been integrated by the whole CCAMP community • Reversion (switch back) • Additional management commands if any needed • Not covered in this I-d: • local recovery • crankback (important in case of heavy load)

  7. Bulk LSP Recovery on Link failure • In case of (component) link failure of a TE Link carrying numerous LSPs • Bundle notification messages does not need additional extension if within the same Interface-ID TLV (use of the IF_ID ERROR_SPEC object) • Master for the failed LSPs may be located at each side of the TE link => the two masters may compete for the same component link (within the same TE link) resource for recovering these LSPs • However, they may (even prior to the failure) agree on which (common) recovery link these LSPs will be recovered otherwise some fragmentation of the TE link components usage may occur

  8. Reversion • Optional mechanism due to potential second hit during to the reversion switching operation • Turn-on/-off (default behaviour settable per policy) either through signalling or policy • Reversion operation • uses exactly the same LSP as the one previously under failure (default behaviour) • implies “testing” the LSP (using Admin_Status) before reversion switching • uses the “bridge and switch” a.k.a “make-before-break” • Keep possibility (e.g. policy or signalling) to clear out the resources on intermediate nodes if reversion switching not possible

  9. What is the Next Step ? • Depending on the working group consensus • First phase achievement (~ towards e2e protocol specification) • Next report April’03 - Deadline 3q’03 to finalize first phase (including signalling protocol specification) Terminology draft-ietf-ccamp-gmpls-recovery-terminology-01.txt Analysis draft-ietf-ccamp-gmpls-recovery-analysis-00.txt Jan’03 March’02 Functional Specification draft-ietf-ccamp-gmpls-recovery-functional-00.txt Jan’03 GMPLS Protocol Specification 3q’03 (first phase closed)

More Related