60 likes | 201 Views
GMPLS Extension Requirements for Virtual Concatenation and Link Aggregation Control. Wataru Imajuku (imajuku.wataru@lab.ntt.co.jp) Yukio Tsukishima (tsukishima.yukio@lab.ntt.co.jp) Young Hwa Kim (yhwkim@etri.re.kr). Summary of Requirements. Basic requirement is to facilitate
E N D
GMPLS Extension Requirements for Virtual Concatenation and Link Aggregation Control Wataru Imajuku (imajuku.wataru@lab.ntt.co.jp) Yukio Tsukishima (tsukishima.yukio@lab.ntt.co.jp) Young Hwa Kim (yhwkim@etri.re.kr) 63rd IETF Paris August 2005
Summary of Requirements • Basic requirement is to facilitate Link capacity control using GMPLS control plane • OTN (ITU-T G.709) control • SDH/SONET (ITU-T G.707) control • Link aggregation (IEEE803.ad) control • Carrier requirements • Resilient capacity control against L2/L3 traffic surge • Enhance reliability of L2/L3 link using diversity • Increase efficiency of • Support not only from NTT, but also from DT • Other possible uses • Flexible resource partitioning or sharing under L1VPN framework [L1VPN] draft-takeda-l1vpn-framework-04.txt • Detailed description about the necessity of extension and requirements can be found in this draft. 63rd IETF Paris August 2005
Ingress Egress GMPLS (Add Upstream bandwidth) Sk So ADD MST=OK CTRL=EOS ADD MST=OK CTRL=EOS CTRL=NRM Discussion Point in -00.txt • Why coordination between LCAS and GMPLS is necessary? • LCAS enables hitless VCn-v addition or removal to/from a group LSP. • LCAS incorporates uni-directional control that requires Admin Status likecontrol for LCAS initiation. • Requirements (Chapter 4) • Requirements for routing protocol extension (Chapter 4.1) • Extension to represent LSP termination capability in GMPLS-TE • Requirements for signaling protocol extension (Chapter 4.2) • LSP Group ID in Call ID Object ? Or Association ID Object? • Admin Status like control to initiate LCAS signaling • FA-consideration (Chapter 5) • Guideline when a group LSP is treated as Forwarding Adjacency. GMPLS Signaling Signaling in overhead 63rd IETF Paris August 2005
Remaining Issues • What should the requirements be for routing extensions ? • Routing extensions enable smooth migration amongst GFP/LCAS/VCAT capable and non-capable nodes. • Some comments negative to define termination capability on the mailing list, but not all vendors support VCAT capability (yet). • Consideration of other constraints. • Ex. Sequence constraint • VC-n-xv removal at Ingress, then Egress removal after the confirmation • Define terminology • Ex. Diego’s question • What is a single LSP ? • Single signaling session or concatenated (aggregated) tunnel ? • But, some people opposed to say that in the mailing list. • Need for a security section 63rd IETF Paris August 2005
Next Step • Charter milestones • Revised by next (64th) IETF meeting • WG charter in 65th IETF meeting • Authors plans and commitments • Seek feedback from carrier’s (DT to be added as co-author) • Add descriptions for OTN and Ether control • Split into mandatory and optional requirements • Add other constraint considerations, if any. • Specific requests: • Comments and close interworking with laison to ITU-T SG15/Q11. • Implementation status • None, but many vendors have already implemented to control virtually concatenated VC-n’s under the GMPLS-control plane. • Request comment and discussion in the mailing list • Need discussion on terminology definition • Need more discussion on routing extensions 63rd IETF Paris August 2005