1 / 9

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

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

bessie
Download Presentation

Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with 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. 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

More Related