PCE WG Quan Xiong
Internet-Draft Shuangping Zhan
Intended status: Standards Track ZTE Corporation
Expires: September 12, 2019 Fangwei Hu
March 11, 2019

PCEP extensions for SR-MPLS-TP


This document proposes a set of extensions to PCEP for Transport Profile of SR-MPLS (SR-MPLS-TP) networks and defines a mechanism to create the bi-directional SR tunnel with PCE.

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 https://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 12, 2019.

Copyright Notice

Copyright (c) 2019 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 (https://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

The Path Computation Element Communication Protocol (PCEP) defined in [RFC5440] provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests.

[I-D.ietf-pce-segment-routing] proposes extensions to PCEP that allow a stateful PCE to compute Traffic Engineering (TE) paths in segment routing (SR) networks. But it is applicable to Multi-protocol Label Switching (MPLS) networks refered as to SR-MPLS. In the context of the Transport Profile of SR-MPLS, referred to in this document as SR-MPLS-TP, a Path Segment uniquely identifies an SR path in a specific context. It is required to extend the PCEP protocol to meet the new requirements for SR-MPLS-TP services. One of the requirements is the bidirectional SR tunnel described in [I-D.ietf-spring-mpls-path-segment].

This document proposes a set of extensions to PCEP for SR-MPLS-TP networks and defines a mechanism to create the bidirectional SR tunnel with PCE.

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

1.2. Terminology

The terminology is defined as [RFC5440], [I-D.ietf-pce-segment-routing] and [I-D.ietf-spring-mpls-path-segment].

MPLS-TP: MPLS transport profile.

SR: Segment Routing.

SR-MPLS: Segment routing over MPLS data plane.

SR-MPLS-TP: Transport Profile of SR-MPLS.

2. The SR-MPLS-TP Architecture with PCE

As described in [I-D.ietf-spring-mpls-path-segment], in transport networks, the centralized controller may calculate the end to end SR paths, and creates the ordered segment list. The centralized controller may be replaced to PCE as the Figure 1 shown. The PCE can calculate the SR paths and a SR path can be initiated by PCE or PCC.

                 +--------------+ PCE  +---------------+
                 |              +---+--+               |
         |       |             SR network              |        |
         |       |                                     |        |
         |   +---+--+           +---+--+           +---+--+     |
         |   |  A   +-----------+   B  +-----------+   C  +     |
         |   +------+           +------+           +------+     |
         |                                                      |
        Ingress Node:                         Egress Node:
        Reverse Path Label                    Forward Path Label
	   (Incoming Label)                       (Outgoing Label)
SR Label Stacks:

        +--------------------+                +--------------------+
        |       Label A      |                |      Label C       |
        +--------------------+                +--------------------+
        |        ...         |                |        ...         |
        +--------------------+                +--------------------+
        |       Label C      |                |      Label A       |
        +--------------------+                +--------------------+
        | Forward Path Label |                | Reverse Path Label |
        +--------------------+                +--------------------+
             Figure 1 The SR-MPLS-TP Architecture with PCE            

It is required to support bidirectional SR tunnel to meet the requirement of SR-MPLS-TP networks. A label named path segment at both ends of the paths was defined to identify the direction of the SR paths as defined in [I-D.ietf-spring-mpls-path-segment]. It mainly aims to bind two unidirectional SR paths to a single bidirectional tunnel.

As the Figure 1 shown, the forward and reverse directions of the bidirectional SR tunnel are identified by the forward and reverse path label respectively. For the ingress node, the forward path label shall be added to the bottom of the label stack and the reverse path label shall be configured to the data plane as incoming label for the SR LSP. And for the egress node, the reverse path label need to be the last one label of the label stack and the forward path label shall be used as outgoing label.

2.1. SR Path SID Allocation

[RFC8402] defined the IGP, BGP, and Binding segments for the SR-MPLS and SRv6 data planes which can be referred as to Segment Identifier (SID). And [I-D.ietf-spring-mpls-path-segment] defined a new type of segment named path segment. So the path segment can also be identified by SID called SR path SID. The path segment may be associated with a unidirectional path.

The path SID allocation includes ingress PCC allocated, egress PCC allocated and PCE allocated in the domain. In case of egress PCC allocated, the ingress PCC needs to comunicate with PCE to send path segment request to egress PCC as the Figure 2 shown. When the ingress PCC requests PCE to compute the SR path with PCReq message, the PCE needs to request egress PCC to allocate the path SID with the PCUpd or PCInit message carrying the Tunnel 1 and LSP 1. The egress PCC needs to identify the allocation function from the initiation message and should not return back PCErr message when checking the local address is not equal with the source address of Tunnel 1. This document defines E bit in section 3.2 carried in LSP object to indicate the egress PCC operation which may not trigger the LSP initiation.

When the path SID is allocated by ingress PCC, it need to inform PCE with the PCRpt message and the latter one sends the notification to egress PCC with PCUpd or PCInit message carried LSP object which set the E bit to 1.

When the path SID is allocated by PCE, it need to inform ingress and egress PCC with PCUpd or PCInit message carrying the Tunnel 1 and LSP 1. But the message sent to egress PCC MUST set the E bit to 1 to avoid triggering the LSP initiation.

                |  PCE |
   PCReq        ^      \   PCUpd/PCInit
   Tunnel 1    /        \  Tunnel 1 
   LSP1       /          \ LSP1, E=1
             /            v
    +--------+    LSP1    +-------+
    |Ingress |----------->|Egress |
    |PCC     |<-----------|PCC    |
    +--------+    LSP2    +-------+
Figure 2 The path SID allocation with PCE


2.2. Associated Bi-directional SR tunnel

As [RFC5654] defined, MPLS-TP MUST support unidirectional, co-routed bidirectional, and associated bidirectional point-to-point transport paths. As [RFC8402] defined, segment routing leverages the source routing paradigm and the sourse node steers a packet through an ordered segment list along a unidirectional path. So for bidirectional SR tunnel, the forward and backward directional paths may be setup by the source node and destination node seperately.

As described in [I-D.ietf-pce-association-bidir], two reverse unidirectional LSPs can be associated as an associated bidirectional tunnel which can be initialed by single-sided and double-sided methods. Based on the discussion above, the associated bidirectional SR tunnel can only be provisioned on both ingress and egress node (PCCs).

The Single-sided initiation can be initiated by ingress SR node and initiate two unidirectional LSPs to headend SR nodes as shown in Figure 3. The Double-sided initiation can be initiated by PCCs or PCE as shown in Figure 4 and 5 respectively. The forward and reverse directional paths can be co-routed or non-corouted. The SR bidirectional tunnel may follow the same path in the forward and reverse directions and initiated as a co-routed associated bidirectional LSP. When the PCE initiated the LSP, the B flag need to be set to indicate a bi-directional LSP as defined in [I-D.ietf-pce-pcep-stateful-pce-gmpls].

                     |   PCE   |
          1,PCReq    ^ /2,PCInit\   2,PCInit
          Tunnel 1  / / Tunnel 1 \  Tunnel 1 
                   / / LSP1       \ LSP2
                  / v              v
            +--------+    LSP1    +-------+
            |Ingress |----------->|Egress |
            |PCC     |<-----------|PCC    |
            +--------+    LSP2    +-------+
Figure 3 PCC-initiated Single-sided Associated Bi-directional LSPs

                          |   PCE   |
              1,PCReq    ^ /2,PCInit \ ^   1,PCReq
             Tunnel 1   / /  Tunnel 1 \ \   Tunnel 1 
                 LSP1  / /  LSP1/LSP2  \ \  LSP2
                      / v               v \
                 +--------+    LSP1    +-------+
                 |Ingress |----------->|Egress |
                 |PCC     |<-----------|PCC    |
                 +--------+    LSP2    +-------+
Figure 4 PCC-initiated Double-sided Associated Bi-directional LSPs

                          |   PCE   |
                 PCInit   /         \   PCInit
                Tunnel 1 /           \   Tunnel 1 
                  LSP1  /             \  LSP2
                       v               v 
                +--------+    LSP1    +-------+
                |Ingress |----------->|Egress |
                |PCC     |<-----------|PCC    |
                +--------+    LSP2    +-------+
Figure 5  PCE-initiated Double-sided Associated Bi-directional LSPs

3. PCEP extensions for SR-MPLS-TP

3.1. ERO extension

As described in [I-D.ietf-spring-mpls-path-segment], it is required to support bi-directional tunnel to meet the requirement of SR networks. But it is the uni-directional tunnel for SR and engineering traffic network as discussed in [I-D.ietf-pce-segment-routing]. The SR path is carried in the Segment Routing Explicit Route Object (SR-ERO), which consists of a sequence of SR subobjects. This document proposes the extension of the SR-ERO Subobject to carry the bi-directional tunnel information as the Figure 6 shown. The subobjects with path SIDs need to be added to the list of the SR-ERO subobjects.


      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
     |L|    Type     |     Length    |  NT   |     Flags   |R|F|S|C|M|
     |                              SID                              |
     //                  NAI(variable,optional)                     //

              Figure 6 Extension of SR-ERO Subobject format

NAI Type (NT) : A new type of NT = 6 is added in this document and it indicates the type and format of the NAI associated with the path SID contained in the object body. When NT is set to 6, the format of NAI field is shown as Figure 7.

R (Reverse Flag -- 1 bit): indicates the SR path direction, when it is clear, it indicates the forward direction and when it is set, it indicates the reverse direction.

The definition of other fields is the same with [I-D.ietf-pce-segment-routing].

      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
     |              Path Label               | TC  |S|       TTL     |
                 Figure 7  NAI for Path Label information

The format of Path Label information is specified as [I-D.ietf-spring-mpls-path-segment].

3.2. E bit in LSP object

The LSP object is defined in [RFC8231]. This document proposes the E bit in flag field of the LSP object as shown in Figure 8:

E (Egress PCC Operation bit): If the bit is set to 1, it indicates that the egress PCC operation with PCUpd or PCInit message and no need to trigger the LSP initiation. A PCE would set the bit to 1 in SR network to request or inform the path SID information.

		  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
     |                PLSP-ID                |         Flag        |E|
     //                        TLVs                                 //
     |                                                               |
                 Figure 8 The extension of LSP object

3.3. Processing Rules

As discussed in [I-D.ietf-spring-mpls-path-segment], the bi-directional SR tunnel is created from two binding unidirectional SR paths. As defined in [RFC8281], the stateful PCE calculates the SR paths and initiates the bi-directional LSP with PCUpd or PCInit message.

The B bit in SRP Object MUST be set and the two unidirectional SR paths may be computed from the forward and reverse direction and sent to the source and destination PCC respectively in SR-ERO object. The path labels which binding the paths may be generated in PCE and sent to the related PCC carried in the bottom of the SR-ERO. When the PCCs at both ends receiving the PCInit message with the labels in SR-ERO subobjects, they may forward the packets from bi-directional tunnel in MPLS-TP networks.

4. Security Considerations


5. IANA Considerations


6. Acknowledgements


7. Normative References

[I-D.ietf-pce-association-bidir] Barth, C., Gandhi, R. and B. Wen, "PCEP Extensions for Associated Bidirectional Label Switched Paths (LSPs)", Internet-Draft draft-ietf-pce-association-bidir-02, November 2018.
[I-D.ietf-pce-pcep-stateful-pce-gmpls] Lee, Y., Zhang, F., Casellas, R., Dios, O. and Z. Ali, "Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks", Internet-Draft draft-ietf-pce-pcep-stateful-pce-gmpls-10, March 2019.
[I-D.ietf-pce-segment-routing] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W. and J. Hardwick, "PCEP Extensions for Segment Routing", Internet-Draft draft-ietf-pce-segment-routing-16, March 2019.
[I-D.ietf-spring-mpls-path-segment] Cheng, W., Li, H., Chen, M., Gandhi, R. and R. Zigler, "Path Segment in MPLS Based Segment Routing Network", Internet-Draft draft-ietf-spring-mpls-path-segment-00, March 2019.
[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.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N. and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, DOI 10.17487/RFC5654, September 2009.
[RFC8231] Crabbe, E., Minei, I., Medved, J. and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S. and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017.
[RFC8402] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S. and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018.

Authors' Addresses

Quan Xiong ZTE Corporation No.6 Huashi Park Rd Wuhan, Hubei 430223 China Phone: +86 27 83531060 EMail: xiong.quan@zte.com.cn
Shuangping Zhan ZTE Corporation Liuxian Rd Shenzhen, 518057 China Phone: +86 755 26773770 EMail: zhan.shuangping@zte.com.cn
Fangwei Hu Individual EMail: hufwei@gmail.com