1 / 5

Kenichi Ogaki ogaki@kddilabs.jp Tomohiro Otani otani@kddilabs.jp

GMPLS constraints consideration for CSPF path computation draft-otani-ccamp-gmpls-cspf-constraints-03.txt. Kenichi Ogaki ogaki@kddilabs.jp Tomohiro Otani otani@kddilabs.jp Arthi Ayyangar arthi@juniper.net Kireeti Kompella kireeti@juniper.net Rajiv Papneja rpapnefa@isocore.com.

nash
Download Presentation

Kenichi Ogaki ogaki@kddilabs.jp Tomohiro Otani otani@kddilabs.jp

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. GMPLS constraints consideration for CSPF path computationdraft-otani-ccamp-gmpls-cspf-constraints-03.txt Kenichi Ogaki ogaki@kddilabs.jp Tomohiro Otani otani@kddilabs.jp Arthi Ayyangar arthi@juniper.net Kireeti Kompella kireeti@juniper.net Rajiv Papneja rpapnefa@isocore.com 66th IETF Montreal July 2006

  2. Summary of draft • This draft fits to the following (former?) charter item • Functional specification of extensions for routing (OSPF, ISIS) and signalling (RSVP-TE) required for path establishment. Protocol formats and procedures that embody these extensions will be done jointly with the WGs supervising those protocols. • This draft • states the problem of GMPLS CSPF path computation • Since these constraints vary and are differently understood among such an multiple switching capability and encoding environment, the path computation results are sometimes different. • tries to provide the guideline to consider GMPLS constraint attributes for CSPF path computation at a source node. • TE attributes must be dealt with correctly for creating GMPLS LSPs in the CSPF path computation considering underlying physical and logical technologies of links as well as nodes. 66th IETF Montreal July 2006

  3. Considered network model Ingress Transit Egress +-----+ link1-2 +-----+ link2-3 +-----+ link3-4 +-----+ |Node1|------------>|Node2|------------>|Node3|------------>|Node4| | |<------------| |<------------| |<------------| | +-----+ link2-1 +-----+ link3-2 +-----+ link4-3 +-----+ • To correctly establish a GMPLS LSP from an ingress to an egress, a possible combination of GMPLS attributes is investigated. • Simple constraintconsiderations for creating a LSP • Switching capabilities (SC) of outgoing links from the ingress and egress nodes must be consistent with each other • SC of all transit links should be consistent with the switching type of a LSP to be created. • Encoding-types of all transit links should be consistent with the encoding type of a LSP to be created. 66th IETF Montreal July 2006

  4. Changes in 02/03 version • Multiple matches of an encoding-type were incorporated considering hierarchy. • An encoding-type may have multiple matches on transit TE links Ex.) LSP encoding (switching type) Transit link encoding --------------------------------------------------------------------------------------------- SONET/SDH (TDM) SONET/SDH SONET/SDH (LSC, FSC) SONET/SDH, Lambda, Fiber Ethernet (TDM) Ethernet, SONET/SDH Ethernet (LSC, FSC) Ethernet, Lambda, Fiber Lambda (LSC, FSC) Lambda, Fiber Fiber (FSC) Fiber Packet (PSC) Packet • A FA-LSP may be used for the hierarchical consideration of SC • New co-author: Rajiv Papneja (Isocore) 66th IETF Montreal July 2006

  5. Further issues & questions • We would like to cover all possible cases to create a concrete guideline of CSPF path computation in terms of GMPLS attributes. • In -03 version, some cases were found to be missing. • Any feedback would be greatly appreciated. • Is this draft categorized as whether BCP or specification? • Since it is not enough information to categorized as BCP (practice!), it should be treated as specification. 66th IETF Montreal July 2006

More Related