1 / 5

Lou Berger lberger@labn Julien Meuric julienuric@orange

Revised Definition of The GMPLS Switching Capability and Type Fields draft-berger-ccamp-swcaps-update-02. Lou Berger lberger@labn.net Julien Meuric julien.meuric@orange.com. Changes. -swcaps-update-00 Presented at last IETF -swcaps-update-01 Included presented planned changes

walden
Télécharger la présentation

Lou Berger lberger@labn Julien Meuric julienuric@orange

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. Revised Definition of The GMPLS Switching Capability and Type Fieldsdraft-berger-ccamp-swcaps-update-02 Lou Berger lberger@labn.net Julien Meuric julien.meuric@orange.com CCAMP - 84th IETF

  2. Changes • -swcaps-update-00 • Presented at last IETF • -swcaps-update-01 • Included presented planned changes • Rename: ILH  ITH • Intra-Layer Hierarchy  Intra-Technology Hierarchy • -swcaps-update-02 • Removed ITH • ITH specific not as mature as rest of draft CCAMP - 84th IETF

  3. Current Draft Scope • Simplifies definition of Switching Capability • Only indicates switching technology • Removes existing overload – no intra-technology significance • Different SCSI formats MUST use different values • Removes existing SCSI format ambiguity • Deprecate intra-layer / unused PSC values • PSC 24 • Keep values used in routing and signaling aligned • No change: keep using IANA Switching Type registry • No substantive change for signaling • Matches discussion on list and last meeting • Aligned with current OTN drafts CCAMP - 84th IETF

  4. Considered Alternatives • Goal: Address two issues for future definitions (i.e., no impact to existing RFC-based implementations, apart from PSC-N that appear to be unused) • Current representation of (1) switching types, (2) technologies, and (3) multiplexing is inconsistent • Current definition of Switching Capability (and types) is overloaded • Alternatives considered – two extremes: • Assign Switching Type per potential SCSI format • i.e., at least one Switching Type per switching technology • different SC specific information field formats imply different Types • Have Switching Type represent (1), (2) and (3) • i.e., for a given technology, as many Types as multiplexing levels(ala PSC-N) Selected Approach CCAMP - 84th IETF

  5. Next steps • Poll to be WG document CCAMP - 84th IETF

More Related