1. Page - 1 70 th IETF Vancouver, B.C., Canada Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with GMPLS Greg Bernstein (ed.)gregb@grotto-networking.com Grotto Networkinggregb@grotto-networking.com Authors: D. Caviglia (Ericsson), R. Rabbat (Google), H. van Helvoort (Huawei). Contributors: Wataru Imajuku (NTT), Julien Meuric (France Telecom), Lyndon Ong (Ciena). draft-ietf-ccamp-gmpls-vcat-lcas-03.txt

2. Page - 2 70 th IETF Vancouver, B.C., Canada Status Changes from 02 text: –Grammar and punctuation fixes. Updated references with newly published RFCs. Next steps from July 2007: –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? Liaison’s from OIF & ITU-T

3. Page - 3 70 th IETF Vancouver, B.C., Canada 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.

4. Page - 4 70 th IETF Vancouver, B.C., Canada Member Signal Configuration Co-RoutedDiversely Route Member Sharing FixedRight sizing bandwidth Extracting bandwidth from mesh Sharing fixed pool DynamicDynamic right sizing Same as above plus resilience Dynamic sharing of connection pool Scenarios and Applications

5. Page - 5 70 th IETF Vancouver, B.C., Canada 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

6. Page - 6 70 th IETF Vancouver, B.C., Canada Proposed Approach & Extensions 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. Use “GMPLS RSVP-TE Signaling Extensions in support of Calls” RFC4974

7. Page - 7 70 th IETF Vancouver, B.C., Canada Comments & Liaison Requirements Refinements: –Set up member LSPs and data plane LSPs (server connections) prior to creation of VCG. –“Member” LSPs (data plane and control plane) can exist after VCG has been removed. Solution Comments: –Some dislike the need for multiple VCGs per call to implement “member sharing” and the above.

8. Page - 8 70 th IETF Vancouver, B.C., Canada Editor’s Assessment General Problem –VCAT/LCAS is a form of inverse multiplex which is inherently a multi-layer “application”. Two approaches to dealing with multi-layer “applications” have been discussed within CCAMP: Call Based Mechanism –Calls can control multiple connections at one or more layers. RFC4974 MRN/MLN Approach –Currently three active MLN drafts (requirements, evaluation, extensions)

9. Page - 9 70 th IETF Vancouver, B.C., Canada Next Steps Update Requirements in Draft? –Procedures… Alternative Solution to meet requirements (and possible extensions)? –Need to move beyond design by “liaison” and see a clearly explained alternative consistent with MLN “philosophy” and minimizing compatibility issues for existing implementations. State of implementations? –How disruptive to consider alternatives at this point?