Network Working Group Suresh Boyapati Internet Draft Juniper Networks Intended Status: Experimental July 1, 2017 Reusage MPLS RSVP Labels during MBB draft-sboyapati-mpls-rsvp-label-reusage-00.txt Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 1, 2018. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(ii), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract MPLS is the heart and soul of the service provider network. MPLS can carry any data payload which gives the flexibility to the service provider to provision new service with any expense. In a scaled MPLS RSVP router during MBB/Global repair, router needs to program large number of labels into PFE. This operation results in lot of label re-computation and label programming. This draft is proposing a solution to label reusage Table of Contents 1. Introduction......................................................3 2. MPLS LSP Problem Statement........................................4 3. How MPLS LSP works ...............................................4 3.1 Selection on MPLS LSP for Voice,Video networks based on Loss and delay Parameters............................... 4.1. Normative References............................................5 1.Introduction MPLS is the heart and soul of the service provider network. MPLS can carry any data payload which gives the flexibility to the service provider to provision new service with any expense. As loss and delay sensitive applications such as Voice and Video are running on MPLS network, they may suffer delays in packet transmission and delivery. So Voice and Video traffic on MPLS network needs low loss and delay LSP's to transfer Voice and Video packets. This draft is proposing a solution to selection of Low loss and latency LSP's for Voice and Video applications using MPLS Loss and Delay measurement parameters. The benefit of this technology results in delivery voice and video packets with best possible lsp i.e. LSP's with less loss and delay. 2. Problem Statement In the below topology 10 20 30 40 50 3 A------B-------C--------D-------E-------F--------G \ / \ / H During MBB/Global Repair, the following sequence of events happen with existing Implementation: 1. A will send PATH message requesting label with new lsp-id. 2. Path message will be processed hop-by-hop by all routers in the ERO path. 3. RESV with New Label will be sent hop-by-hop to the upstream. a. Labels before the MBB 10,20,30,40,50,3. b. Labels after the MBB 11,22,33,44,55,3 c. It is important to note that labels changes before and after the MBB. 4. Routers will program new label in PFEs and switches the LSP to new Label. Observations with existing implementation : 1. During MBB every router in ERO path, need to maintain two PSB states with two different labels. 2. During MBB event every router will need to reprogram the label and switch to new Label. 3. After expiration of user defined timer/default timers, old label will be deleted. 4. In a highly scaled MPLS LSP router, this process is very expensive and CPU intensive . Proposed Solution: 1. During MBB event, Router A will send PATH message to the Down Stream router with new lsp-id and same tunnel-id & Extended tunnel-ID. 2. This PATH message will be processed hop-by-hop by all routers in the ERO PATH. 3. Down Stream router will provide the label based on below conditions: a. If Tunnel-id & Extended tunnel-ID in the incoming PATH message is part of existing PSB/RSB then provide the same existing in used Label. b. If Tunnel-id & Extended tunnel-ID in the incoming PATH message is not part existing PSB/RSB then provide a new Label from available label base. 4. After expiration of configured/user defined timers, depending on 3a or 3b (above) , router will either delete the old instance of lsp-id or delete combination of old instance lsp-id & its associated label. Example 1 with proposed solution (MBB to the same ERO PATH) : 10 20 30 40 50 3 A------B-------C--------D-------E-------F--------G \ / \ / H In the above topology , 1. LSP is signaled from A to G. (A---B---C---D----E---F---G.) 2. Due to Auto BW adjustment MBB will take place and selects PATH A---B---C---D----E---F---G. 3. Router A will send a PATH message to Router G, with same tunnel-id and new lsp-id and PATH message will be processed in hop-by-hop by every router in the path . 4. Every Router will verify their PSB/RSB for the matching tunnel-id 5. If tunnel-id & Extended tunnel-ID matches with existing PSB/RSB, then send the same Label which is already in use for existing tunnel-id & Extended tunnel-ID combination i.e. label used for psb1. 6. In the above topology example labels computed for new instance of lsp-id will same as labels used in old lsp-id i.e. 10,20,30,40,50. a. Labels before the MBB 10,20,30,40,50,3. b. Labels after the MBB 10,20,30,40,50,3. c. It is important to note that labels DO NOT change before and after the MBB. 7. By signalling of same label to Up Stream router, no RE to PFE communication is required regarding label Change. Example 2 with proposed solution (MBB to the different ERO PATH than the original ERO) : 10 20 30 40 50 3 A------B-------C--------D-------E-------F--------G \ / 60 \ / 40 H In the above topology , 1. LSP is signaled from A to G. (A---B---C---D----E---F---G.) 2. Due to Auto BW adjustment MBB will take place and selects PATH A---B---C----H----E---F----G. 3. Router A will send a PATH message to Router G, with same tunnel-id and new lsp-id and PATH message will be processed in hop-by-hop by every router. 4. Every Router will verify their PSB/RSB for the matching tunnel-id & Extended tunnel-ID 5. If tunnel-id & Extended tunnel-ID matches with existing PSB/RSB, then send the same Label to the Up Stream Router. 6. In the above topology example Router E PATH message was received from Router H. When router E compares PSB/RSB it has a matching existing session with label 40 sent upstream to Router D. 7. Router E will use the same label (40) and send it to new Up Stream Router H. 8. On Router H, when tunnel-id & Extended tunnel-ID was compared in PSB/RSB, there is no existing label match, hence Router H will signal a new label 60 to Router C. 9. By this signalling of same label to Up Stream router, no RE to PFE communication is required regarding label Change. References: 4.1. Normative References [RFC2205] Resource ReSerVation Protocol (RSVP) [RFC3209] RSVP-TE: Extensions to RSVP for LSP Tunnels Author Address Suresh Boyapati Juniper Networks Sunnyvale,CA USA Email: sureshkb@juniper.net