Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with GMPLS

1. Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with GMPLS draft-ietf-ccamp-gmpls-vcat-lcas-03.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). 70th IETF Vancouver, B.C., Canada

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

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

4. Member Signal Configuration Scenarios and Applications 70th IETF Vancouver, B.C., Canada

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

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

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

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

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