sboyapati-mpls-rsvp-label-reusage-00.txt

Internet DRAFT - draft-sboyapati-mpls-rsvp-label-reusage

draft-sboyapati-mpls-rsvp-label-reusage

Last Version:	draft-sboyapati-mpls-rsvp-label-reusage-00.txt	Tracker Entry
Date:	`03-Jul-2017`
Disposition:	expired

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.

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