1 / 5

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

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

larrywatson
Download Presentation

Tomohiro Otani otani@kddilabs.jp Kenichi Ogaki ogaki@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-01.txt Tomohiro Otani otani@kddilabs.jp Kenichi Ogaki ogaki@kddilabs.jp Arthi Ayyangar arthi@juniper.net Rajiv Papneja rpapnefa@isocore.com 63rdIETF Paris August 2005

  2. Summary of draft • This draft fits to the following charter item • Definition of the mechanisms required to determine the route and properties of an established path (tunnel tracing). • This draft • states the problem of GMPLS CSPF path computation • Since these constraints vary and are differently understood among such an integrated environment (especially between optical and packet transport point of view), 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 LSP in the CSPF path computation considering underlying physical and logical technologies of links as well as nodes. 63rdIETF Paris August 2005

  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 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. 63rdIETF Paris August 2005

  4. Changes in 01 version • Multiple matches of encoding-type and SC was incorporated considering hierarchy. • Encoding-type and SC may have multiple matches on transit TE links LSP encoding TE Link encoding • Packet Packet, SONET/SDH, Ethernet, Lambda, Fiber • SONET/SDH SONET/SDH, Lambda, Fiber • Ethernet Ethernet, Lambda, Fiber • Lambda Lambda, Fiber LSP switching-type TE Link SC • Lambda Lambda, Fiber • FA-LSP should be used for other hierarchical considerations • New co-author • Rajiv papneja (Isocore) 63rdIETF Paris August 2005

  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. • Especially L2SC • Any feedback would be greatly appreciated. • Is this categorized as whether BCP or specification? Since it is not enough information to categorized as BCP (practice!), it may be as specification. 63rdIETF Paris August 2005

More Related