1 / 6

VCAT/LCAS and GMPLS

VCAT/LCAS and GMPLS. draft-ietf-ccamp-gmpls-vcat-lcas-01.txt Greg Bernstein (Grotto Networking) Diego Caviglia (Ericsson) Richard Rabbat (Google) Huub van Helvoort (Huawei) IETF 68: Prague. Process. Main editor reverts to Greg Bernstein Large, ad hoc discussion mailing list

iago
Download Presentation

VCAT/LCAS and GMPLS

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. VCAT/LCAS and GMPLS draft-ietf-ccamp-gmpls-vcat-lcas-01.txt Greg Bernstein (Grotto Networking) Diego Caviglia (Ericsson) Richard Rabbat (Google) Huub van Helvoort (Huawei) IETF 68: Prague

  2. Process • Main editor reverts to Greg Bernstein • Large, ad hoc discussion mailing list • Greg Bernstein (Grotto Networking) • Diego Caviglia (Ericsson) • Richard Rabbat (Google) • Huub van Helvoort (Huawei) • Julien Meuric (France Telecom) • Deborah Brungard (at&t) • Lyndon Ong (Ciena) • Jonathan Sadler (Tellabs) • Stephen Shew (Nortel) • Jim Jones (Alcatel-Lucent) • Dan Li (Huawei) • Evelyne Roch (Nortel) • Fred Gruman (Fujitsu) • Vijay Pandian (Sycamore) • Adrian Farrel (Old Dog Consulting) • To be involved in the discussions, comment on the CCAMP list or send us email

  3. Progress and Plans • No update to the draft since last meeting • Plenty of discussion • Reaching agreement on the requirements • Working out what the solution might be • Planning a new revision soon(!) • Completely stabilise the requirements • First draft of solution • Will be ready for review • We should liaise this to ITU-T and OIF who are interested in this work

  4. Requirements • Allow TDM LSPs to be signalled to support virtual concatenation • RFC 4606 defines mechanisms if all VCG components follow the same path (i.e., a single control plane LSP) • Hardware now allows VCG components to follow different paths (i.e., separate control plane LSPs) • Need mechanisms for… • Associating LSPs to form a single group • Defining the characteristics of the group • Size of group (i.e., capacity) • Granularity of group members • Number of group members • A pre-established pool of ‘spare’ LSPs that can be added to a VCG • Determining which ports/interfaces at the egress can support the VCG

  5. Moving Towards a Solution • Association could be though: • Association object • GMPLS Call • Seems like a more natural construct given that the association is only for end points • VCG characteristics can be Call parameters • Management of a spare pool needs some more thought, but there are some ideas • This function needs LCAS to work • Use a Call per “pool” • Use LCAS to manage the VCGs

  6. Determining End-Point Capabilities • Feels like a routing function • But it doesn’t scale • Consider VCG may be spread across ports • Perhaps put some basic features as TE node capabilities in routing • Diverse path VCG support • Perhaps put some basic features as TE link capabilities in routing • LCAS support • Remaining function is in Call “negotiation”

More Related