1 / 10

A fast LSP-alert mechanism

A fast LSP-alert mechanism. draft-kini-mpls-fast-lsp-alert-00. by Sriganesh Kini and H. Autumn Liu. IETF 77, Anaheim, March 21-26, 2010. Problem Statement. Some applications require multiple LSRs along a LSP to be alerted. Any delay degrades the application

tod
Télécharger la présentation

A fast LSP-alert mechanism

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. A fast LSP-alert mechanism draft-kini-mpls-fast-lsp-alert-00 by Sriganesh Kini and H. Autumn Liu IETF 77, Anaheim, March 21-26, 2010

  2. Problem Statement • Some applications require multiple LSRs along a LSP to be alerted. Any delay degrades the application • Typical application draft-kini-mpls-ring-frr-facility-backup • Current alert mechanisms (TTL, GAL) can alert only a single LSR • Generating separate alert messages to each (upto 255) LSR introduces delay • Control plane forwarding (if used) also introduces delay

  3. Solution requirements and framework • Simple enough to be implemented in hardware or firmware • Should not introduce new addressing identifiers • Should not require forwarding based on other addressing schemes (e.g. IP) • Should be in line with basic MPLS packet processing paradigm

  4. Solution – originating packets • Alert message is encapsulated in the G-ACh of the LSP. • The following values MUST be used for TTL : • TTL of LSP label - set to 1 • TTL of GAL - set to number of LSRs to be alerted (255 if all downstream LSRs) • A bit in ACH is defined as Fast LSP Alert bit or FLA-bit to indicate modified packet processing

  5. Solution (contd) – ACH format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved |X| Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • X = Fast LSP Alert bit or FLA-bit

  6. Solution (contd) – Rx processing • Rx packet processing when FLA-bit is set • Additional copy of the G-ACh packet (with FLA-bit set) MUST be made if LSR is not the LSP end-point. This copy will be forwarded further along the LSP • GAL TTL processing MUST be done according to swap operation rules of RFC 3443 (oTTL = iTTL – 1) • Packet MUST be forwarded according to the ILM of the LSP • oTTL of LSP label MUST be set to 1

  7. Solution characteristics • TTL of GAL ensures packet does not loop • TTL of LSP label ensures each LSR is alerted • In line with MPLS packet processing rules for forwarding and TTL expiry RFC3031,3032,3443,5586. • Only exception is in the LSP label where oTTL = iTTL • However GAL TTL ensures TTL semantics preserved • Simple enough for hardware/firmware implementation

  8. Example L1 L2 L3 L4 LSP-A Label-1 S=0, TTL=1 LSP-A Label-2 S=0, TTL=1 LSP-A Label-3 S=0, TTL=1 GAL S=1, TTL=255 GAL S=1, TTL=254 GAL S=1, TTL=253 ACH FLA-bit is set ACH FLA-bit is set ACH FLA-bit is set ACH TLV Header/TLVs If present ACH TLV Header/TLVs If present ACH TLV Header/TLVs If present G-ACh message G-ACh message G-ACh message

  9. Applicability • Uni-directional and bi-directional LSPs • P2P and P2MP LSPs • Other LSP types for future study • MPLS and MPLS-TP

  10. Questions/Comments?

More Related