Network Working Group Z. Li
Internet-Draft X. Chen
Intended status: Standards Track Huawei Technologies
Expires: September 13, 2017 March 12, 2017

PCEP Extensions for Tunnel Segment
draft-li-pce-tunnel-segment-02

Abstract

[I-D.li-spring-tunnel-segment] introduces a new type of segment, Tunnel Segment, for the segment routing. Tunnel segment can be used to reduce SID stack depth of SR path, span the non-SR domain or provide differentiated services. A binding label can be assigned to tunnel segment. An upstream node can use such a binding label for steering traffic into the appropriate tunnel. This document specifies a set of extensions to PCEP to support that PCC reports binding label of tunnel to PCE and that PCE allocates label for tunnel and updates label binding of tunnel to PCC.

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

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 September 13, 2017.

Copyright Notice

Copyright (c) 2017 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

[I-D.li-spring-tunnel-segment] introduces a new type of segment, Tunnel Segment, for the segment routing. Tunnel segment can be used to reduce SID stack depth of SR path, span the non-SR domain or provide differentiated services. A binding label can be assigned to tunnel segment. An upstream node can use such a binding label for steering traffic into the appropriate tunnel. The tunnel segment can be allocated for RSVP-TE tunnel, SR-TE tunnel or IP tunnel.

[I-D.li-spring-tunnel-segment] defines the requirement of control plane to support use cases of tunnel segment. The PCE related requirements are as follows:

-- PCEP extensions SHOULD be introduced to advertise the binding relationship between a SID/label and the corresponding tunnel from a PCC to a PCE. Attributes of the tunnel MAY be carried optionally.

-- PCE SHOULD support to allocate SID/label for the corresponding tunnel dynamically.

-- PCEP extensions SHOULD be introduced to distribute the binding relationship between a SID/label and the corresponding tunnel from a PCE to a PCC. Attributes of the tunnel MAY be carried optionally.

This document specifies the protocol extensions to PCEP to support these requirements defined in [I-D.li-spring-tunnel-segment].

2. Terminology

SR: Segment Routing

SR-TE: Segment Routing Traffic Engineering

SR-TE Tunnel: Segment Routing Traffic Engineering Tunnel

This document uses the terms defined in [RFC5440]: PCC, PCE, PCEP Peer.

The following terms are defined in [I-D.ietf-pce-pce-initiated-lsp]:

PCE-initiated LSP: LSP that is instantiated as a result of a request from the PCE.

The following terms are defined in [I-D.chen-pce-pce-initiated-ip-tunnel]:

IP Tunnel: Tunnel that uses IP encapsulation.

PCE-initiated IP Tunnel: IP Tunnel that is instantiated as a result of a request from the PCE.

3. Procedures

3.1. Procedure for PCC Reporting Label Binding

In the procedure for PCC reporting the label binding PCC allocates the label and reports the label binding for the tunnel according to the local policy PCC. For report the label binding information, there are following options:

Option 1: [I-D.zhao-pce-pcep-extension-for-pce-controller] specifies the procedures and PCEP protocol extensions for using the PCE as the central controller where LSPs are calculated/setup/initiated and label forwarding entries are downloaded to PCC. It introduces the LABEL object to specify the label binding information in PCLabelUpd message. The label carried in LABEL object is mapped to specific LSP carried in LSP object or FEC carried in FEC object. The LABEL object defined in the document is to allocate label from the PCE to PCC and is not appropriate to represent the label binding for the tunnel which can be carried in other PCE objects.

Option 2: [I-D.sivabalan-pce-binding-label-sid] proposes an approach for reporting binding label/SID to Path Computation Element (PCE) for supporting PCE-based Traffic Engineering policies. It introduces the optional TLV called "TE-PATH-BINDING TLV" to carry binding label or SID for a TE path. This TLV is limited to traffic engineering and not appropriate for tunnel segment.

Option 3: PCEP-LS [I-D.dhodylee-pce-pcep-ls] extends the Path Computation Element Communication Protocol (PCEP) with TED population capability. A PCEP LS Report message (also referred to as LSRpt message) is sent by a PCC to a PCE to report the TED state. The LS object is a mandatory object which carries TE information of a TE node or a TE link. [I-D.wu-pce-pcep-ls-sr-extension] introduces new extensions of PCEP-LS to export path segment information for Segment Routing.

This document adopts Option 3 and introduces a new type of TLV, TUNNEL-LABEL-BINDING TLV, which is a new optional TLV defined to report the label mapping for the tunnel in the case of Segement Routing. The tunnel can be PCE-initiated tunnel or created by PCC. [I-D.chen-pce-pce-initiated-ip-tunnel] defines the PCE-initiated IP tunnel and Tunnel object. Tunnel related TLVs defined in [I-D.chen-pce-pce-initiated-ip-tunnel] will be used when report label binding for the tunnel. In order to support Tunnel Segment for MPLS TE tunnel and SR-TE tunnel, this document introduces two new tunnel types for tunnel related TLVs: RSVP-TE tunnel and SR-TE tunnel.

In this document LS object will be extended to carry the label mapping information for the tunnel. A new Object-Type value is defined for the LS object to indicate Tunnel Segment. The LS object in LSRpt message MUST carry both TUNNEL-LABEL-BINDING TLV and Tunnel Identifier TLV with the new Object-Type value. If a PCC wants to modify a previously reported label, it MUST send a LSRpt message with the TUNNEL-LABEL-BINDING TLV containing the new label binding value. If the Tunnel Identifier TLV is missing, the PCE will generate an error with error-type 6 (mandatory object missing) and error-value which means Tunnel Identifier TLV missing and close the session. If the TUNNEL-LABEL-BINDING TLV is missing, the PCE will generate an error with error-type 6 (mandatory object missing) and error-value which means TUNNEL-LABEL-BINDING TLV missing and close the session.

If a PCE does not recognize the TUNNEL-LABEL-BINDING TLV, it MUST ignore the TLV in accordance with [RFC5440]. If a PCE recognizes the TLV but does not support the TLV, it MUST send PCErr with Error-Type = 2 (Capability not supported). If there are more than one TUNNEL-LABEL-BINDING TLVs, only the first TLV MUST be processed and the rest MUST be silently ignored.

If a PCE does not recognize the Tunnel Identifier TLV, it MUST ignore the TLV in accordance with [RFC5440]. If a PCE recognizes the TLV but does not support the TLV, it MUST send PCErr with Error-Type = 2 (Capability not supported). If there are more than one Tunnel Identifier TLVs, only the first TLV MUST be processed and the rest MUST be silently ignored.

3.2. Procedure for PCE Downloading Label Binding

[I-D.zhao-pce-pcep-extension-for-pce-controller] has defined the Label Update Message (also referred to as PCLabelUpd) that is a PCEP message sent by a PCE to a PCC to download label or update the label mapping. The same message is also used to cleanup the label mapping. In the procedure for PCE downloading the label binding for Tunnel Segment PCE is responsible for allocating the label for PCE-initiated tunnel or the tunnel initiated by PCC and reported to PCE.

[I-D.chen-pce-pce-initiated-ip-tunnel] defines the PCE-initiated IP tunnel and the TUNNEL object. PCE uses the Label Update Message to download the label mapping for the tunnel in the case of Segment Routing. The PCLabelUpd Message is defined in [I-D.zhao-pce-pcep-extension-for-pce-controller] and the extension of the PCLabelUpd message for tunnel segment is defined as follows:

   <pce-label-update> ::= (<pce-label-download>|<pce-label-map>
                           |<pce-label-tunnel-map>)                                                                             
Where:
   <pce-label-tunnel-map> ::= <SRP>
                              <LABEL>
                              <TUNNEL>

TUNNEL object refers to the definition of [I-D.chen-pce-pce-initiated-ip-tunnel] and this document extends the use of TUNNEL object in PCLabelUpd message. In order to support Tunnel Segment for MPLS TE tunnel and SR-TE tunnel, this document introduces two new tunnel types for TLVs used in TUNNEL object: RSVP- TE tunnel and SR-TE tunnel. The TUNNEL object is an optional object and used in the tunnel segment mode in PCLabelUpd message. TUNNEL object in PCLabelUpd message MUST carry the TUNNEL-IDENTIFIER TLV with Tunnel ID set. If the TLV is missing, the PCC will generate a PCErr message with Error-Type=6 (mandatory object missing) and Error-Value which means Tunnel Identifier TLV missing and close the session.

To cleanup the label mapping for the tunnel the SRP object MUST set the R (remove) bit.

PCE downloads the label mapping to the ingress node of the tunnel and create the label forwarding entry for the tunnel segment. PCE can also download the label mapping to other nodes which will use the label mapping of the tunnel for SR path computation.

4. Objects

4.1. LS object

LS object is defined in [I-D.draft-dhodylee-pce-pcep-ls]. This document defines a new Object-Type value for LS object:

o Tunnel Segment: LS Object-Type is 5 (to be assigned by IANA).

5. TLVs

5.1. Tunnel Label Binding TLV

 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              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Binding Label                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   

              Figure 1: TUNNEL-LABEL-BINDING TLV

The type of the TLV is to be assigned by IANA and it has a fixed length of 4 octets.

The value contains the following fields:

Binding Label: contains the binding label which is generic.

5.2. PATH-SETUP-TYPE TLV

The PATH-SETUP-TYPE TLV is defined in [I-D.sivabalan-pce-lsp-setup-type]. This document defines following new PST value:

o PST = 4(to be assigned by IANA): tunnel segment mode that means path setup will use the tunnel segment.

On a PCLabelUpd message, the PST=4 in PATH-SETUP-TYPE TLV in SRP object indicates that this LSP was setup using the tunnel segment.

5.3. Tunnel Related TLV

[I-D.chen-pce-pce-initiated-ip-tunnel] defines tunnel related TLVs including Tunnel Identifier TLV, Tunnel Name TLV, Tunnel Parameter TLV and Tunnel Attribute TLV. Tunnel Identifier TLV and Tunnel Parameter TLV contain the Tunnel Type field and only IP tunnel types are defined. This document defines following two new tunnel types to support RSVP-TE tunnel and SR-TE tunnel. The values are to be assigned by IANA and MUST NOT conflict with the registry for "BGP Tunnel Encapsulation Attribute Tunnel Types" [RFC5512] assigned by IANA.

      Tunnel Type                             Value
      ---------------                         -----
      RSVP-TE                                 14 
      SR-TE                                   15     

6. IANA Considerations

TBD.

7. Security Considerations

TBD.

8. References

8.1. Normative References

[I-D.chen-pce-pce-initiated-ip-tunnel] Chen, X. and Z. Li, "PCE-initiated IP Tunnel", Internet-Draft draft-chen-pce-pce-initiated-ip-tunnel-00, September 2015.
[I-D.dhodylee-pce-pcep-ls] Dhody, D., Lee, Y. and D. Ceccarelli, "PCEP Extension for Distribution of Link-State and TE Information.", Internet-Draft draft-dhodylee-pce-pcep-ls-07, March 2017.
[I-D.li-spring-tunnel-segment] Li, Z. and N. Wu, "Tunnel Segment in Segment Routing", Internet-Draft draft-li-spring-tunnel-segment-01, March 2016.
[I-D.wu-pce-pcep-ls-sr-extension] Wu, N. and Z. Li, "PCEP Link-State Extensions for Segment Routing", Internet-Draft draft-wu-pce-pcep-ls-sr-extension-00, September 2015.
[I-D.zhao-pce-pcep-extension-for-pce-controller] Zhao, Q., Li, Z., Dhody, D. and C. Zhou, "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs", Internet-Draft draft-zhao-pce-pcep-extension-for-pce-controller-04, January 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, DOI 10.17487/RFC5512, April 2009.

8.2. Informative References

[I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, S. and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", Internet-Draft draft-ietf-pce-pce-initiated-lsp-09, March 2017.
[I-D.sivabalan-pce-binding-label-sid] Sivabalan, S., Filsfils, C., Previdi, S., Tantsura, J., Hardwick, J. and M. Nanduri, "Carrying Binding Label/Segment-ID in PCE-based Networks.", Internet-Draft draft-sivabalan-pce-binding-label-sid-02, October 2016.
[I-D.sivabalan-pce-lsp-setup-type] Sivabalan, S., Medved, J., Minei, I., Crabbe, E. and R. Varga, "Conveying path setup type in PCEP messages", Internet-Draft draft-sivabalan-pce-lsp-setup-type-02, June 2014.

Authors' Addresses

Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing, 100095 China EMail: lizhenbin@huawei.com
Xia Chen Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing, 100095 China EMail: jescia.chenxia@huawei.com