Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths
draft-palle-pce-stateful-pce-p2mp-06

Abstract

The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs. This document provides extensions required for PCEP so as to enable the usage of a stateful PCE capability in supporting point-to-multipoint (P2MP) TE LSPs.

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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on October 25, 2015.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

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

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 2. Terminology
• 3. Supporting P2MP TE LSP for Stateful PCE
• 3.1. Motivation
• 3.2. Objectives
• 4. Functions to Support P2MP TE LSPs for Stateful PCEs
• 5. Architectural Overview of Protocol Extensions
• 5.1. Extension of PCEP Messages
• 5.2. Capability Advertisement
• 5.3. State Synchronization
• 5.4. LSP Delegation
• 5.5. LSP Operations
• 5.5.1. Passive Stateful PCE
• 5.5.2. Active Stateful PCE
• 6. PCEP Object Extensions
• 6.1. Extension of LSP Object
• 6.2. P2MP-LSP-IDENTIFIER TLV
• 6.3. S2LS Object
• 7. PCEP Message Extensions
• 7.1. The PCRpt Message
• 7.2. The PCUpd Message
• 7.3. The PCReq Message
• 7.4. The PCRep Message
• 7.5. Example
• 7.5.1. P2MP TE LSP Update Request
• 7.5.2. P2MP TE LSP Report
• 7.6. Report and Update Message Fragmentation
• 7.6.1. Report Fragmentation Procedure
• 7.6.2. Update Fragmentation Procedure
• 8. Non-Support of P2MP TE LSPs for Stateful PCE
• 9. Manageability Considerations
• 9.1. Control of Function and Policy
• 9.2. Information and Data Models
• 9.3. Liveness Detection and Monitoring
• 9.4. Verify Correct Operations
• 9.5. Requirements On Other Protocols
• 9.6. Impact On Network Operations
• 10. IANA Considerations
• 10.1. STATEFUL-PCE-CAPABILITY TLV
• 10.2. Extension of LSP Object
• 10.3. Extension of PCEP-Error Object
• 10.4. PCEP TLV Type Indicators
• 11. Security Considerations
• 12. Acknowledgments
• 13. References
• 13.1. Normative References
• 13.2. Informative References
• Authors' Addresses

1. Introduction

As per [RFC4655], the Path Computation Element (PCE) is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed.

[RFC4857] describes how to set up point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The PCE has been identified as a suitable application for the computation of paths for P2MP TE LSPs ([RFC5671]).

The PCEP is designed as a communication protocol between PCCs and PCEs for point-to-point (P2P) path computations and is defined in [RFC5440]. The extensions of PCEP to request path computation for P2MP TE LSPs are described in [RFC6006].

Stateful PCEs are shown to be helpful in many application scenarios, in both MPLS and GMPLS networks, as illustrated in [I-D.ietf-pce-stateful-pce-app]. These scenarios apply equally to P2P and P2MP TE LSPs. [I-D.ietf-pce-stateful-pce] provides the fundamental extensions needed for stateful PCE to support general functionality for P2P TE LSP. Complementarily, this document focuses on the extensions that are necessary in order for the deployment of stateful PCEs to support P2MP TE LSPs.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Terminology

Terminology used in this document is same as terminology used in [I-D.ietf-pce-stateful-pce] and [RFC6006].

3. Supporting P2MP TE LSP for Stateful PCE

3.1. Motivation

[I-D.ietf-pce-stateful-pce-app] presents several use cases, demonstrating scenarios that benefit from the deployment of a stateful PCE including optimization, recovery, etc which are equally applicable to P2MP TE LSPs. [I-D.ietf-pce-stateful-pce] defines the extensions to PCEP for P2P TE LSPs. Complementarily, this document focuses on the extensions that are necessary in order for the deployment of stateful PCEs to support P2MP TE LSPs.

In addition to that, the stateful nature of a PCE simplifies the information conveyed in PCEP messages since it is possible to refer to the LSPs via PLSP-ID. For P2MP this is an added advantage, where the size of message is much larger. Incase of stateless PCE, a modification of P2MP tree requires encoding of all leaves along with the paths in PCReq message, but using a stateful PCE with P2MP capability, the PCEP message can be used to convey only the modifications (the other information can be retrieved from the P2MP LSP identifier in the LSP database (LSPDB)).

3.2. Objectives

The objectives for the protocol extensions to support P2MP TE LSP for stateful PCE are same as the objectives described in section 3.2 of [I-D.ietf-pce-stateful-pce].

4. Functions to Support P2MP TE LSPs for Stateful PCEs

[I-D.ietf-pce-stateful-pce] specifies new functions to support a stateful PCE. It also specifies that a function can be initiated either from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C).

This document extends these functions to support P2MP TE LSPs.

Capability Advertisement (E-C,C-E):

both the PCC and the PCE must announce during PCEP session establishment that they support PCEP Stateful PCE extensions for P2MP using mechanisms defined in Section 5.2.

LSP State Synchronization (C-E):

after the session between the PCC and a stateful PCE with P2MP capability is initialized, the PCE must learn the state of a PCC's P2MP TE LSPs before it can perform path computations or update LSP attributes in a PCC.

LSP Update Request (E-C):

a stateful PCE with P2MP capability requests modification of attributes on a PCC's P2MP TE LSP.

LSP State Report (C-E):

a PCC sends an LSP state report to a PCE whenever the state of a P2MP TE LSP changes.

LSP Control Delegation (C-E,E-C):

a PCC grants to a PCE the right to update LSP attributes on one or more P2MP TE LSPs; the PCE becomes the authoritative source of the LSP's attributes as long as the delegation is in effect (See Section 5.5 of [I-D.ietf-pce-stateful-pce]); the PCC may withdraw the delegation or the PCE may give up the delegation at any time.

[Editor's Note - An update to [I-D.sivabalan-pce-disco-stateful] is needed to support autodiscovery of stateful PCEs with P2MP capability. This can be undertaken after WG adoption.]

5. Architectural Overview of Protocol Extensions

5.1. Extension of PCEP Messages

New PCEP messages are defined in [I-D.ietf-pce-stateful-pce] to support stateful PCE for P2P TE LSPs. In this document these messages are extended to support P2MP TE LSPs.

Path Computation State Report (PCRpt):

Each P2MP TE LSP State Report in a PCRpt message can contain actual P2MP TE LSP path attributes, LSP status, etc. An LSP State Report carried on a PCRpt message is also used in delegation or revocation of control of a P2MP TE LSP to/from a PCE. The extension of PCRpt message is described in Section 7.1.

Path Computation Update Request (PCUpd):

Each P2MP TE LSP Update Request in a PCUpd message MUST contain all LSP parameters that a PCE wishes to set for a given P2MP TE LSP. An LSP Update Request carried on a PCUpd message is also used to return LSP delegations if at any point PCE no longer desires control of a P2MP TE LSP. The PCUpd message is described in Section 7.2.

5.2. Capability Advertisement

During PCEP Initialization Phase, as per Section 7.1.1 of [I-D.ietf-pce-stateful-pce], PCEP speakers advertises Stateful capability via Stateful PCE Capability TLV in open message. Two new flags are defined for the STATEFUL-PCE-CAPABILITY TLV defined in [I-D.ietf-pce-stateful-pce] and updated in [I-D.ietf-pce-pce-initiated-lsp] and [I-D.ietf-pce-stateful-sync-optimizations].

Two new bits N (P2MP-CAPABILITY) and M (P2MP-LSP-UPDATE-CAPABILITY) are added in this document:

N (P2MP-CAPABILITY - 1 bit):

if set to 1 by a PCC, the N Flag indicates that the PCC is willing to send P2MP LSP State Reports whenever P2MP LSP parameters or operational status changes.; if set to 1 by a PCE, the N Flag indicates that the PCE is interested in receiving LSP State Reports whenever LSP parameters or operational status changes. The P2MP-CAPABILITY Flag must be advertised by both a PCC and a PCE for PCRpt messages P2MP extension to be allowed on a PCEP session.

M (P2MP-LSP-UPDATE-CAPABILITY - 1 bit):

if set to 1 by a PCC, the M Flag indicates that the PCC allows modification of P2MP LSP parameters; if set to 1 by a PCE, the M Flag indicates that the PCE is capable of updating P2MP LSP parameters. The P2MP-LSP-UPDATE-CAPABILITY Flag must be advertised by both a PCC and a PCE for PCUpd messages P2MP extension to be allowed on a PCEP session.

A PCEP speaker should continue to advertise the basic P2MP capability via mechanisms as described in [RFC6006].

5.3. State Synchronization

State Synchronization operations described in Section 5.4 of [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well.

5.4. LSP Delegation

LSP delegation operations described in Section 5.5 of [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well.

5.5. LSP Operations

5.5.1. Passive Stateful PCE

LSP operations for passive stateful PCE described in Section 5.6.1 of [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well.

The Path Computation Request and Response message format for P2MP TE LSPs is described in Section 3.4 and Section 3.5 of [RFC6006] respectively.

The Request and Response message for P2MP TE LSPs are extended to support encoding of LSP object, so that it is possible to refer to a LSP with a unique identifier and simplify the PCEP message exchange. For example, incase of modification of one leaf in a P2MP tree, there should be no need to carry the full P2MP tree in PCReq message.

The extension for the Request and Response message for passive stateful operations on P2MP TE LSPs are described in Section 7.3 and Section 7.4. The extension for the Path Computation LSP State Report (PCRpt) message is described in Section 7.1.

5.5.2. Active Stateful PCE

LSP operations for active stateful PCE described in Section 5.6.2 of [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well.

The extension for the Path Computation LSP Update (PCUpd) message for active stateful operations on P2MP TE LSPs are described in Section 7.2.

6. PCEP Object Extensions

The PCEP TLV defined in this document is compliant with the PCEP TLV format defined in [RFC5440].

6.1. Extension of LSP Object

LSP Object is defined in Section 7.3 of [I-D.ietf-pce-stateful-pce]. It specifies PLSP-ID to uniquely identify an LSP that is constant for the life time of a PCEP session. Similarly for P2MP tunnel, PLSP-ID identify a P2MP TE LSP uniquely. This document adds the following flags to the LSP Object:

N (P2MP bit):

If the bit is set to 1, it specifies the message is for P2MP TE LSP which MUST be set in PCRpt or PCUpd message for a P2MP TE LSP.

F (Fragmentation bit):

If the bit is set to 1, it specifies the message is fragmented.

If P2MP bit is set, the following P2MP-LSP-IDENTIFIER TLV MUST be present in LSP object.

6.2. P2MP-LSP-IDENTIFIER TLV

The P2MP LSP Identifier TLV MUST be included in the LSP object in PCRpt message for RSVP-signaled P2MP TE LSPs. If the TLV is missing, the PCE will generate an error with error-type 6 (mandatory object missing) and error-value TBD (P2MP-LSP-IDENTIFIERS TLV missing) and close the PCEP session.

The P2MP LSP Identifier TLV MAY be included in the LSP object in PCUpd message for RSVP-signaled P2MP TE LSPs. The special value of all zeros for this TLV is used to refer to all paths pertaining to a particular PLSP-ID.

There are two P2MP LSP Identifier TLVs, one for IPv4 and one for IPv6.

The format of the IPV4-P2MP-LSP-IDENTIFIER TLV is shown in the following figure:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Type=[TBD]          |           Length=16           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   IPv4 Tunnel Sender Address                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             LSP ID            |           Tunnel ID           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Extended Tunnel ID                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             P2MP ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      

                   
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Type=[TBD]          |           Length=40           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                  IPv6 tunnel sender address                   |
+                          (16 octets)                          +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             LSP ID            |           Tunnel ID           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                       Extended Tunnel ID                      |
+                          (16 octets)                          +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             P2MP ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      

                   
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Flags                       |    O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                      Optional TLVs                          //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      

    
<PCRpt Message> ::= <Common Header>
                  <state-report-list>
Where:

<state-report-list> ::= <state-report>
                      [<state-report-list>]

<state-report> ::= [<SRP>]
                    <LSP>
                    <end-point-path-pair-list>
                    <attribute-list>
Where:

<end-point-path-pair-list>::=
                   [<END-POINTS>]
                   [<S2LS>]                             
                   <path>
                   [<end-point-path-pair-list>]
                   
<path> ::= (<ERO>|<SERO>) 
           [<RRO>]
           [<path>]

<attribute-list> is defined in [RFC5440] and
extended by PCEP extensions.
   

    
   <PCUpd Message> ::= <Common Header>
                       <update-request-list>
                        
   Where:

   <update-request-list> ::= <update-request>
                             [<update-request-list>]

   <update-request> ::= <SRP>
                        <LSP>
                        <end-point-path-pair-list>
                                               
<attribute-list>
   Where:
   
   <end-point-path-pair-list>::=
                   [<END-POINTS>] 
                   <path>
                   [<end-point-path-pair-list>]
                   
   <path> ::= (<ERO>|<SERO>) 
              [<path>]

   <attribute-list> is defined in [RFC5440] and 
   extended by PCEP extensions.
   

   <PCReq Message>::= <Common Header>
                      <request>
   where:
   <request>::= <RP>
                <end-point-rro-pair-list>
                [<LSP>]
                [<OF>]
                [<LSPA>]
                [<BANDWIDTH>]
                [<metric-list>]
                [<IRO>]
                [<LOAD-BALANCING>]

   where:
   <end-point-rro-pair-list>::=<END-POINTS>[<RRO-List>][<BANDWIDTH>]
                               [<end-point-rro-pair-list>]

   <RRO-List>::=<RRO>[<BANDWIDTH>][<RRO-List>]
   <metric-list>::=<METRIC>[<metric-list>]         

   <PCRep Message>::= <Common Header>
                      <response>
   
   <response>::=<RP>
                [<end-point-path-pair-list>]
                [<NO-PATH>]
                [<attribute-list>]

   where:

   <end-point-path-pair-list>::=
                   [<END-POINTS>]<path>[<end-point-path-pair-list>]

   <path> ::= (<ERO>|<SERO>) [<path>]

   <attribute-list>::=[<LSP>]
                      [<OF>]
                      [<LSPA>]
                      [<BANDWIDTH>]
                      [<metric-list>]
                      [<IRO>]        

 
           Common Header
           SRP 
           LSP with P2MP flag set
           END-POINTS for leaf type 3
             ERO list

 
           Common Header
           LSP with P2MP flag set
           END-POINTS for leaf type 1
             S2LS (O=DOWN)
             ERO list (empty)

 
           Common Header
           LSP with P2MP flag set
           END-POINTS for leaf type 2
             S2LS (O=UP)
             ERO list 

 
           Common Header
           LSP with P2MP flag set
           END-POINTS for leaf type 3
             S2LS (O=UP)
             ERO list 
           END-POINTS for leaf type 3
             S2LS (O=DOWN)
             ERO list    

 
           Common Header
           LSP with P2MP flag set
           END-POINTS for leaf type 4
             S2LS (O=ACTIVE)
             ERO list 
           END-POINTS for leaf type 4
             S2LS (O=DOWN)
             ERO list    

   
    Bit    Description           Reference

    TBD     P2MP-CAPABILITY      This.I-D
    TBD     P2MP-LSP-UPDATE-     This.I-D
            CAPABILITY
    

   
    Bit    Description           Reference

    TBD     P2MP                 This.I-D
    TBD     Fragmentation        This.I-D

    

   
    Error-Type  Meaning
       6        Mandatory Object missing
                  Error-value=TBD: S2LS object missing
                  Error-value=TBD: P2MP-LSP-IDENTIFIER TLV missing
       18       P2MP Fragmentation Error
                  Error-value= TBD. Fragmented Report 
                      failure                  
                  Error-value= TBD. Fragmented Update 
                      failure                  
       19       Invalid Operation
                  Error-value= TBD. Attempted LSP State Report 
                      for P2MP if stateful PCE capability 
                      for P2MP was not advertised
                  Error-value= TBD. Attempted LSP Update Request 
                      for P2MP if active stateful PCE capability 
                      for P2MP was not advertised
    

     
       Value     Meaning                           Reference
         TBD     P2MP-IPV4-LSP-IDENTIFIERS         This.I-D
         TBD     P2MP-IPV6-LSP-IDENTIFIERS         This.I-D