Framework for latency and loss traffic engineering application draft-fuxh-ccamp-delay-loss-te-framework-00.txt draft-fuxh-ccamp-delay-loss-rsvp-te-ext-00.txt.

Slides:



Advertisements
Similar presentations
CCAMP WG, IETF 80th, Prague, Czech Republic draft-gonzalezdedios-subwavelength-framework-00 Framework for GMPLS and path computation support of sub-wavelength.
Advertisements

IETF 78, Maastricht, Netherlands, July 25-30, 2010Page - 1 Requirement and Framework for Multi Stages Multiplexing Configuration in G.709 network draft-fuxh-ccamp-multi-stage-multiplex-config-req-01.
RSVP-TE Extensions for SRLG Configuration of FA
RSVP-TE extensions for services aware MPLS draft-fuxh-mpls-delay-loss-rsvp-te-ext-00 Xihua Fu, Malcolm Betts, Qilei Wang ZTE Dave McDysan, Andrew Malis.
MPLS - 74th IETF San Francisco1 Composite Transport Group (CTG) Framework and Requirements draft-so-yong-mpls-ctg-framework-requirement-01.txt draft-so-yong-mpls-ctg-framework-requirement-01.txt.
IETF 77, Anaheim, March 21-26, 2010Page - 1 Requirements for Path Ownership Transfer between Management Plane and Control Plane in a MPLS-TP network draft-bao-mpls-tp-path-transfer-reqs-00.txt.
© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-1 MPLS TE Overview Understanding MPLS TE Components.
Requirement and protocol for WSON and non-WSON interoperability CCAMP WG, IETF 81th, Quebec City, Canada draft-shimazaki-ccamp-wson-interoperability-00.
1 draft-ali-ccamp-rc-objective-function-metric-bound-02.txt draft-ali-ccamp-rsvp-te-include-route-02.txt draft-ali-ccamp-xro-lsp-subobject-02.txt CCAMP.
MPLS - 75th IETF Stockholm1 Composite Transport Group (CTG) Framework and Requirements draft-so-yong-mpls-ctg-framework-requirement-02.txt draft-so-yong-mpls-ctg-framework-requirement-02.txt.
OSPF Traffic Engineering (TE) Express Path draft-giacalone-ospf-te-express-path-00.txt Spencer Giacalone, Alia Atlas, John Drake, Dave Ward.
MPLS additions to RSVP Tunnel identification Tunnel parameter negotiation Routing policy distribution Routing debugging information Scalability improvements.
Introduction to MPLS and Traffic Engineering Zartash Afzal Uzmi.
December 20, 2004MPLS: TE and Restoration1 MPLS: Traffic Engineering and Restoration Routing Zartash Afzal Uzmi Computer Science and Engineering Lahore.
MPLS and Traffic Engineering
1IMIC, 8/30/99 Constraint-Based Unicast and Multicast: Practical Issues Bala Rajagopalan NEC C&C Research Labs Princeton, NJ
A General approach to MPLS Path Protection using Segments Ashish Gupta Ashish Gupta.
Introduction to MPLS and Traffic Engineering
A General approach to MPLS Path Protection using Segments Ashish Gupta Ashish Gupta.
Control and Traffic Management Paper: Banerjee et al.: ” Generalized multiprotocol label switching: an overview of signaling enhancements and recovery.
SMUCSE 8344 Constraint-Based Routing in MPLS. SMUCSE 8344 Constraint Based Routing (CBR) What is CBR –Each link a collection of attributes (performance,
Delay and Loss Traffic Engineering Problem Statement for MPLS draft-fuxh-mpls-delay-loss-te-problem-statement-01 November 8, 2012 IETF 85, Atlanta 8/3/121.
MPLS - 73nd IETF Minneaplis1 Composite Transport Group (CTG) Framework and Requirements draft-so-yong-mpls-ctg-framework-requirement-00.txt draft-so-yong-mpls-ctg-framework-requirement-00.txt.
1 Multi Protocol Label Switching Presented by: Petros Ioannou Dept. of Electrical and Computer Engineering, UCY.
1 Multi-Protocol Label Switching (MPLS). 2 MPLS Overview A forwarding scheme designed to speed up IP packet forwarding (RFC 3031) Idea: use a fixed length.
Introduction to MPLS and Traffic Engineering Zartash Afzal Uzmi.
1 Framework for GMPLS based control of Flexi-grid DWDM networks draft-ogrcetal-ccamp-flexi-grid-fwk-02 CCAMP WG, IETF 86 Oscar González de Dios, Telefónica.
PCEP extensions for the computation of route offers with price draft-carrozzo-pce-pcep-route-price-00 G. Carrozzo, G. Bernini, G. Landi {g.carrozzo, g.bernini,
Extensions to OSPF-TE for Inter-AS TE draft-ietf-ccamp-ospf-interas-te-extension-01.txt Mach Renhai
ZTE CORPORATION Extensions of BRPC and PCEP to Support Inter- AS Bidirectional LSP Path Computation draft-wang-pce-inter-as-extentions-00 Xuerong.
1 Multi Topology Routing for OSPFv3 (draft-mirtorabi-mt-ospfv3-00.txt) Sina Mirtorabi
OSPF extensions for supporting spectrum sub-band allocation draft-wang-ccamp-flexigrid-wavelength-range-ospf-02 Qilei Wang Xihua.
1 IETF- 56 – TE WG- SAN FRANCISCO Inter-AS MPLS Traffic Engineering draft-vasseur-inter-AS-TE-00.txt Jean-Philippe Vasseur – Cisco Systems Raymond Zhang.
IETF-69th Chicago1 Extensions to GMPLS RSVP-TE for Bidirectional Lightpath with the Same Wavelength draft-xu-rsvpte-bidir-wave-00 Sugang Xu, Hiroaki Harai,
Support Shared Mesh Protection in MPLS-TP March 27, 2011 Ping Pan (Infinera) Sam Aldrin (Huawei) Luyuan Fang (Cisco)
Framework for G.709 Optical Transport Network (OTN) draft-ietf-ccamp-gmpls-g709-framework-05 CCAMP WG, IETF 82 nd Taipei.
IETF-70th Vancouver1 Extensions to GMPLS RSVP-TE for Bidirectional Lightpath with the Same Wavelength draft-xu-rsvpte-bidir-wave-01 Sugang Xu, Hiroaki.
1 Requirements for GMPLS-based multi-region and multi-layer networks (MRN/MLN) draft-ietf-ccamp-gmpls-mln-reqs-01.txt CCAMP WG, IETF 66 Jul. 10, 2006 Kohei.
Kireeti Kompella draft-kompella-mpls-rmr-01
June 4, 2003Carleton University & EIONGMPLS - 1 GMPLS Generalized Multiprotocol Label Switching Vijay Mahendran Sumita Ponnuchamy Christy Gnanapragasam.
(Slide set by Norvald Stol/Steinar Bjørnstad
1 Requirements for Very Fast Setup of GMPLS LSPs draft-malis-ccamp-fast-lsps-01 Andrew G. Malis Ronald A. Skoog Haim Kobrinski George Clapp John E. Drake.
1 Ping and Traceroute for GMPLS LSPs in Non-Packet Switched Networks draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Zafar Ali, Roberto Cassata (Cisco.
Inter-area MPLS TE Architecture and Protocol Extensions
Applicability of Existing Solutions to the Problem Space draft-takeda-l1vpn-applicability-03.txt.
70th IETF Vancouver, December 2007 CCAMP Working Group Status Chairs: Deborah Brungard : Adrian Farrel :
Inter-AS PCE Requirements draft-bitar-zhang-interas-PCE-req-01.txt Nabil Bitar (Verizon) Dean Cheng (Cisco) Kenji Kumaki (KDDI) Raymond Zhang (BT Infonet)
66th IETF, Montreal, July 2006 PCE Working Group Meeting IETF-66, July 2006, Montreal A Backward Recursive PCE-based Computation (BRPC) procedure to compute.
What do we put in the TED? Which TE links from the network should appear in the Traffic Engineering Database at a Label Switching Router? An attempt to.
1 73th IETF, CCAMP WG, Minneapolis, MN, USA November 2008 RSVP-TE based Impairments Collection Mechanism Zafar Ali, Roberto Cassata (Cisco Systems) Marco.
Slide title In CAPITALS 50 pt Slide subtitle 32 pt GMPLS RSVP-TE extensions for OAM Configuration IETF-81 Quebec.
OSPF Traffic Engineering (TE) Express Path Updates draft-giacalone-ospf-te-express-path-01.txt Spencer Giacalone, Alia Atlas, John Drake, Stefano Previdi,
Extensions to PCEP for Hierarchical Path Computation Elements PCE draft-zhang-pcep-hierarchy-extensions-00 Fatai Zhang Quintin Zhao.
RSVP-TE Signaling Extension for Explicit Control of LSP Boundary in MRN/MLN draft-fuxh-ccamp-boundary-explicit-control-ext-01.txt draft-fuxh-ccamp-boundary-explicit-control-ext-01.txt.
1 draft-ali-ccamp-te-metric-recording-02.txt CCAMP – IETF 84 – Vancouver July - August 2012 Zafar Ali Cisco Systems Clarence Filsfils  Cisco Systems Kenji.
Requirements for the Resilience of Control Plane in GMPLS (draft-kim-ccamp-cpr-reqts-00.txt) Young Hwa Kim CCAMP WG (59 th IETF) Apr.04,
GMPLS extensions to communicate latency as a Traffic Engineering performance metric draft-wang-ccamp-latency-te-metric-03.txt draft-wang-ccamp-latency-te-metric-03.txt.
GMPLS extensions to communicate latency as a Traffic Engineering performance metric draft-wang-ccamp-latency-te-metric-00.txt draft-wang-ccamp-latency-te-metric-00.txt.
RSVP Setup Protection draft-shen-mpls-rsvp-setup-protection-03
Ning So Andrew Malis Dave McDysan Lucy Yong Fredric Jounay Yuji Kamite
Zhenbin Li, Li Zhang(Huawei Technologies)
Jean-Philippe Vasseur – Cisco Systems Raymond Zhang - Infonet
RSVP-TE Signaling Extension for Explicit Control of LSP Boundary in MRN/MLN draft-fuxh-ccamp-boundary-explicit-control-ext-02.txt Xihua Fu Qilei Wang.
RSVP Setup Protection draft-shen-mpls-rsvp-setup-protection-02
MPLS Traffic Engineering
Iftekhar Hussain (Presenter),
CHAPTER 8 Network Management
Authors Mach Chen Andrew G. Malis
DetNet Information Model Consideration
Spencer Giacalone, Alia Atlas, John Drake, Dave Ward
Presentation transcript:

Framework for latency and loss traffic engineering application draft-fuxh-ccamp-delay-loss-te-framework-00.txt draft-fuxh-ccamp-delay-loss-rsvp-te-ext-00.txt draft-fuxh-ccamp-delay-loss-te-framework-00.txt draft-fuxh-ccamp-delay-loss-rsvp-te-ext-00.txt Xihua Fu, Malcolm Betts, Qilei Wang ZTE Dave McDysan, Andrew Malis Verizon John E Drake Juniper Spencer Giacalone Thomson Reuters

Background The key driver is stock/commodity trading and data center applications. The purpose is to make an accurate end-to-end prediction of latency and packet loss before a path is established. Track – draft-wang-ccamp-latency-te-metric was presented in 79th and 80th in CCAMP. draft-wang-ccamp-latency-te-metric – Chairs (Lou and Acee) suggest the overlap OSPF portions of draft- wang-ccamp-latency-te-metric be combined with draft-giacalone- ospf-te-express-pathof draft- wang-ccamp-latency-te-metricdraft-giacalone- ospf-te-express-path – Chairs (Lou and Ross) suggest framework and rsvp-te should be done in MPLS WG. – Restructure the draft-wang into a framework and some protocol specific parts (e.g., OSPF and RSVP-TE) to address the issues raised in the framework.

Document structure Based on the suggestion from chairs, framework and rsvp-te documents will be renamed with title “mpls” and posted to MPLS WG. draft-fuxh-mpls-delay-loss-te-framework-00 draft-giacalone-ospf-te-express-path-01 draft-fuxh-mpls-delay-loss-rsvp-te-ext-00

Requirement Identification NumRequirementImplication REQ1To communicate latency, latency variation and packet loss as a link’s traffic engineering performance metric into IGP. OSPF Extension Local Configuration To control latency and loss IGP message advertisement and avoid unstable when the latency, latency variation and packet loss value changes. REQ2Path computation entity MUST have the capability to compute one end-to-end path with latency and packet loss constraint. Path Computation REQ3To indicate a traffic flow should select a component link with minimum latency and/or packet loss value, maximum acceptable latency and/or packet loss value and maximum acceptable delay variation value RSVP-TE Extension [CL-REQ]CL-REQ REQ4To indicate FA selection or FA-LSP creation with minimum latency and/or packet loss value, maximum acceptable latency and/or packet loss value and maximum acceptable delay variation value. RSVP-TE Extension

Requirement Identification NumRequirementImplication REQ5To accumulate latency of links and nodes along one LSP across multi-domain (e.g., inter-AS, inter-Area or multi-layer) so that an latency validation decision can be made at the source node. RSVP-TE Extension REQ6To support pre-defined protection or dynamic re- routing, if a "provisioned" end-to-end LSP latency and/or loss could not meet SLA anymore. Network Planning REQ7To support re-routing latency and/or loss end-to-end cost, if a “provisioned” end-to-end LSP latency and/or loss performance is improved because of some segment performance promotion. Network Planning REQ8To indicate the switchover of the LSP according to maximum acceptable change latency and packet loss value in order to avoid unstable Local Configuration

Purpose draft-fuxh-ccamp-delay-loss-rsvp-te-ext-00.txt draft-fuxh-ccamp-delay-loss-rsvp-te-ext-00.txt The RSVP-TE portions in draft-wang-ccamp-latency-te-metric is moved into this draft.draft-wang-ccamp-latency-te-metric The purpose is to extend RSVP-TE protocol to promote SLA experience of latency and packet loss application in inter-AS, inter-Area or multi-layer network. – REQ3: To facilitate the component link selection or creation based on latency and packet loss constraint. – REQ4: To facilitate the FA selection or FA-LSP creation based on latency and packet loss constraint. – REQ5: To accumulate latency of links and nodes along one LSP across multi-domain so that an latency validation decision can be made at the source node.

Component Link or FA Selection/Creation Latency SLA Parameters ERO subobject – It is added into the boundary node of FA-LSP or Composite Link. – It explicitly conveys the latency SLA parameter used for component link or FA selection and creation based on the latency constraint. I bit: indicates whether a traffic flow shall select a component link or FA with the minimum latency value or not. V bit: indicates whether a traffic flow shall select a component link or FA with the minimum latency variation value or not.

Assume there are following component links within one composite link. – Component link1: latency = 5ms, latency variation = 15 us – Component link2: latency = 10ms, latency variation = 6 us – Component link3: latency = 20ms, latency variation = 3 us – Component link4: latency = 30ms, latency variation = 1 us Assume there are following SLA Parameters for component link selection. Only Component link2 could be qualified. – I bit = TRUE – V bit = FALSE – Maximum Acceptable Latency Value= 35 ms – Maximum Acceptable Latency Variation Value = 10us Assume there are following SLA Parameters for component link selection. There may be no any qualified component links. Priority may be used for latency and variation. – I bit = TRUE – V bit = TRUE – Maximum Acceptable Latency Value= 35 ms – Maximum Acceptable Latency Variation Value = 10us Component Link or FA Selection/Creation

Latency Accumulation and Verification Latency Accumulation Object – It is carried in Path/Resv message in order to accumulate the latency of each links and nodes along the path which is across multi-domain. – When the source node desires to accumulate (i.e., sum) the total latency of one end-to-end LSP, the "Latency Accumulating desired“ flag should be set in the LSP_ATTRIBUTES object of Path/Resv. Latency Accumulation sub-TLV Latency Accumulation Object Non- linearly

Latency Accumulation and Verification Required Latency Object – It is carried in the LSP_ATTRIBUTES object of Path/Resv message. – If the source node makes the intermediate node have the capability to verify the accumulated latency, the "Latency Verifying desired" flag should be set in the LSP_ATTRIBUTES object of Path/Resv. – Intermediate nodes could reject the Path or Resv if the accumulated latency exceeds required latency value in this object.

Next steps Refine the document according to the feedback of meeting and mailing list.