Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with GMPLS draft-ietf-ccamp-gmpls-vcat-lcas-02.txt Greg Bernstein (ed.) gregb@grotto-networking.com Grotto Networking Authors: D. Caviglia (Ericsson), R. Rabbat (Google), H. van Helvoort (Huawei). Contributors: Wataru Imajuku (NTT), Julien Meuric (France Telecom), Lyndon Ong (Ciena). © Grotto Networking 2004

Changes from 01 Changed section 3.1 from "Multiple VCAT Groups per GMPLS endpoint" to "Multiple VCAT Groups per Interface" to improve clarity. Changed terminology from "component" signal to "member" signal where possible (not quoted text) to avoid confusion with link bundle components. Added "Dynamic, member sharing" scenario. Clarified requirements with respect to scenarios and the LCAS and non-LCAS cases. Added text describing needed signaling information between the VCAT endpoints to support required scenarios. Added text to describe: co-signaled, co-routed, data plane LSP, control plane LSP and their relationship to the VCAT/LCAS application. © Grotto Networking 2004

Definitions and Terminology Virtual Concatenation Group (VCG) member This is an individual data plane signal of one of the permitted SDH, SONET, OTN or PDH signal types. Co-signaled member set One or more VCG members (or potential members) set up via the same control plane signaling exchange. Note that all members in a co-signaled set follow the same route. Co-routed member set One or more VCG members that follow the same route. Although VCG members may follow the same path, this does not imply that they we co-signaled. Data plane LSP for our purposes here this is equivalent to an individual VCG member. Control plane LSP A control plane entity that can control multiple data plane LSPs. For our purposes here this is equivalent to our co-signaled member set. © Grotto Networking 2004

Member Signal Configuration Scenarios and Applications Co-Routed Diversely Route Member Sharing Fixed Right sizing bandwidth Extracting bandwidth from mesh Sharing fixed pool Dynamic Dynamic right sizing Same as above plus resilience Dynamic sharing of connection pool © Grotto Networking 2004

Required Information (derived requirements) GMPLS signaling for LCAS-capable interfaces must support all the previous scenarios Non-LCAS capable interfaces must support the fixed subset of the previous scenarios Required Information (derived requirements) Type of member signal Total number of member to be in the VCG A mechanism to identify a VCG and its associated members © Grotto Networking 2004

Current Support and Extensions Single VCG composed of a single co-signaled member set Currently supported by GMPLS signaling. Informational text in section 4.1 of draft VCGs composed of more that one co-signaled member sets Information required by end points and proposed mechanism for transfer in section 4.2 of draft. © Grotto Networking 2004

The VCG Layer VCG VCG Layer Call Information Composed of one or more member signals Analogous to a call being composed of multiple connections  Can use call signaling mechanisms VCG Layer Call Information Signal type (of member signals) Number of VCG members LCAS requirement Maximum number of VCGs per call (support for member sharing scenario) © Grotto Networking 2004

Proposed Approach & Extensions Use “GMPLS RSVP-TE Signaling Extensions in support of Calls” Single VCG per Call (details in draft) Additional TLVs for VCG information Use Call ID to identify VCG in the single VCG case (non-member sharing) Multiple VCG per Call (member sharing) Outline of solution in draft Makes use of additional signaling to coordinate VCGs and assign/remove member signals to VCGs Uses tunnel id, LSP id, and label ordinal to identify member signals. © Grotto Networking 2004

Solidify single VCG per call solution Next Steps Text clean up Solidify single VCG per call solution Formats for TLVs, etc… Reflect latest GMPLS call support draft/RFC Member sharing solution Will this be specified or just an informational section with future standardization TBD? © Grotto Networking 2004