1. Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with GMPLS
draft-ietf-ccamp-gmpls-vcat-lcas-02.txt
Greg Bernstein (ed.) 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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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