1 / 5

Usage of The RSVP Association Object draft-ietf-ccamp-assoc-ext-00

Usage of The RSVP Association Object draft-ietf-ccamp-assoc-ext-00. Lou Berger <lberger@labn.net> Francois Le Faucheur <flefauch@cisco.com> Ashok Narayanan < ashokn@cisco.com>. Question from last IETF: One draft or two?. draft-ietf-ccamp-assoc-info-0 1 covered :

kolton
Download Presentation

Usage of The RSVP Association Object draft-ietf-ccamp-assoc-ext-00

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. Usage of The RSVP Association Objectdraft-ietf-ccamp-assoc-ext-00 Lou Berger <lberger@labn.net> Francois Le Faucheur <flefauch@cisco.com> Ashok Narayanan <ashokn@cisco.com> CCAMP - 81st IETF

  2. Question from last IETF: One draft or two? • draft-ietf-ccamp-assoc-info-01 covered: • Informational usage for GMPLS recovery • Standards track extensions for non-GMPLS recovery usage and Extended association • Discussed at IETF 80:Should Information and Standards track sections be separated? E.g.: • “Usage of The RSVP Association Object” • “RSVP Association Object Extensions ” Consensus to separate This presentation covers #2 CCAMP - 81st IETF

  3. First sections moved from draft-ietf-ccamp-assoc-info-01 • Non-Recovery Usage (Per IETF 76, 77) • Standards Track • But don’t modify usage for Recovery • Provides informational guidance for Recovery • Non-Recovery Usage • Reuse recovery rules • Match LSPs with identical ASSOCIATION objects • All fields: Type, ID, & Source • Multiple associations are possible all association objects need to examined. • Applies to LSP and non-LSP forms of RSVP • Allow for association based on Path or Resv messages • Upstream Initiated Association (Path state matching) • Downstream Initiated Association (Resv state matching) • No cross-direction association No Change CCAMP - 81st IETF

  4. Second sections moved from draft-ietf-ccamp-assoc-info-01 • IPv4 and IPv6 Extended ASSOCIATION Objects • Revised per plan discussed at IETF 79 (no changes since) • Supports • Association identifiers > 16 bits • MPLS TP identifiers – ICC and Global ID • Format: No Change 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num(199)| C-Type (TBA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Type | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Association Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Association Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : . : : Extended Association ID : : . : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Per RFC 4872 Global ID: <0> | <2|4-byte ASN> 4 bytes >= 0 bytes, 32-bit aligned [<ICC> <0x00>] [<data>] CCAMP - 81st IETF

  5. Next steps • Draft is now stable • Split resolved final open issue • Ready to move forward / LC • Comments? CCAMP - 81st IETF

More Related