[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

PCE WG                                                        Quan Xiong
Internet-Draft                                                Fangwei Hu
Intended status: Standards Track                         Shuangping Zhan
Expires: April 25, 2019                                  ZTE Corporation
                                                        October 22, 2018


                     PCEP extensions for SR MPLS-TP
                draft-xiong-pce-pcep-extension-sr-tp-02

Abstract

   This document proposes a set of extensions to PCEP for Segment
   Routing in MPLS Transport Profile (MPLS-TP) networks and defines a
   mechanism to create the bi-directional SR tunnel in SR networks 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 April 25, 2019.

Copyright Notice

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



Quan Xiong, et al.       Expires April 25, 2019                 [Page 1]


Internet-Draft       PCEP extensions for SR MPLS-TP         October 2018


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  The SR MPLS-TP Architecture with PCE  . . . . . . . . . . . .   3
     2.1.  SR Path SID Allocation  . . . . . . . . . . . . . . . . .   4
     2.2.  Associated Bi-directional SR tunnel . . . . . . . . . . .   5
   3.  PCEP extensions for SR MPLS-TP  . . . . . . . . . . . . . . .   6
     3.1.  ERO extension . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  E bit in LSP object . . . . . . . . . . . . . . . . . . .   7
     3.3.  Processing Rules  . . . . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Informative References  . . . . . . . . . . . . . . . . .   8
     7.2.  Normative References  . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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.  [I-D.hu-spring-sr-tp-use-case] describes
   the use case of SR tunnel to be deployed in MPLS Transport Profile
   (MPLS-TP) network.  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.cheng-spring-mpls-path-segment].

   This document proposes a set of extensions to PCEP for Segment
   Routing in MPLS Transport Profile networks and defines a mechanism to
   create the bidirectional SR tunnel in SR networks 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].





Quan Xiong, et al.       Expires April 25, 2019                 [Page 2]


Internet-Draft       PCEP extensions for SR MPLS-TP         October 2018


1.2.  Terminology

   The terminology is defined as [RFC5440],
   [I-D.ietf-pce-segment-routing] , [I-D.cheng-spring-mpls-path-segment]
   and [I-D.hu-spring-sr-tp-use-case].

2.  The SR MPLS-TP Architecture with PCE

   As described in [I-D.hu-spring-sr-tp-use-case], in MPLS-TP 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.


                                       |
                                       |
                                       V
                                   +---+--+
                    +--------------+ 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



Quan Xiong, et al.       Expires April 25, 2019                 [Page 3]


Internet-Draft       PCEP extensions for SR MPLS-TP         October 2018


   It is required to support bidirectional SR tunnel to meet the
   requirement of 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.cheng-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 backward 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 to by Segment Identifier
   (SID).  And [I-D.cheng-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.



Quan Xiong, et al.       Expires April 25, 2019                 [Page 4]


Internet-Draft       PCEP extensions for SR MPLS-TP         October 2018


                                          +------+
                                      |  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.  Based on the defination of co-routed bidirectional path, the
   forward and backward directions follow the same route (links and
   nodes) across the network and must be setup, monitored and protected
   as a single entity.

   However, 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.  So
   the co-routed birectional SR paths can not be provisioned by PCE.

   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 Double-sided initiation can be initiated by PCCs or PCE.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 initialed as a co-routed
   associated bidirectional LSP.








Quan Xiong, et al.       Expires April 25, 2019                 [Page 5]


Internet-Draft       PCEP extensions for SR MPLS-TP         October 2018


3.  PCEP extensions for SR MPLS-TP

3.1.  ERO extension

   As described in [I-D.hu-spring-sr-tp-use-case], 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 3 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 3 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 4.

   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 4  NAI for Path Label information






Quan Xiong, et al.       Expires April 25, 2019                 [Page 6]


Internet-Draft       PCEP extensions for SR MPLS-TP         October 2018


   The format of Path Label information is specified as
   [I-D.cheng-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:

   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 5 The extension of LSP object


3.3.  Processing Rules

   As discussed in [I-D.cheng-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

   TBD.







Quan Xiong, et al.       Expires April 25, 2019                 [Page 7]


Internet-Draft       PCEP extensions for SR MPLS-TP         October 2018


5.  IANA Considerations

   TBD.

6.  Acknowledgements

   TBD.

7.  References

7.1.  Informative References

   [I-D.hu-spring-sr-tp-use-case]
              hu, f., Xiong, Q., Mirsky, G., and W. Cheng, "Segment
              Routing Transport Profile Use Case", draft-hu-spring-sr-
              tp-use-case-01 (work in progress), March 2018.

7.2.  Normative References

   [I-D.cheng-spring-mpls-path-segment]
              Cheng, W., Wang, L., Li, H., Chen, M., Gandhi, R., Zigler,
              R., and S. Zhan, "Path Segment in MPLS Based Segment
              Routing Network", draft-cheng-spring-mpls-path-segment-03
              (work in progress), October 2018.

   [I-D.ietf-pce-association-bidir]
              Barth, C., Gandhi, R., and B. Wen, "PCEP Extensions for
              Associated Bidirectional Label Switched Paths (LSPs)",
              draft-ietf-pce-association-bidir-01 (work in progress),
              May 2018.

   [I-D.ietf-pce-segment-routing]
              Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
              and J. Hardwick, "PCEP Extensions for Segment Routing",
              draft-ietf-pce-segment-routing-14 (work in progress),
              October 2018.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/info/rfc5440>.





Quan Xiong, et al.       Expires April 25, 2019                 [Page 8]


Internet-Draft       PCEP extensions for SR MPLS-TP         October 2018


   [RFC5654]  Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
              Sprecher, N., and S. Ueno, "Requirements of an MPLS
              Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
              September 2009, <https://www.rfc-editor.org/info/rfc5654>.

   [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,
              <https://www.rfc-editor.org/info/rfc8231>.

   [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,
              <https://www.rfc-editor.org/info/rfc8281>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

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


   Fangwei Hu
   ZTE Corporation
   No.889 Bibo Rd
   Shanghai  201203
   China

   Phone: +86 21 68896273
   Email: hu.fangwei@zte.com.cn









Quan Xiong, et al.       Expires April 25, 2019                 [Page 9]


Internet-Draft       PCEP extensions for SR MPLS-TP         October 2018


   Shuangping Zhan
   ZTE Corporation
   Liuxian Rd
   Shenzhen  518057
   China

   Phone: +86 755 26773770
   Email: zhan.shuangping@zte.com.cn











































Quan Xiong, et al.       Expires April 25, 2019                [Page 10]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/