PCEP extensions for SR-TP
draft-xiong-pce-pcep-extension-sr-tp-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Quan Xiong , fangwei hu , Shuangping Zhan | ||
| Last updated | 2018-08-27 (Latest revision 2018-03-05) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xiong-pce-pcep-extension-sr-tp-01
PCE WG Quan Xiong
Internet-Draft Fangwei Hu
Intended status: Standards Track Shuangping Zhan
Expires: February 28, 2019 ZTE Corporation
August 27, 2018
PCEP extensions for SR-TP
draft-xiong-pce-pcep-extension-sr-tp-01
Abstract
This document proposes a set of extensions to PCEP for Segment
Routing in MPLS Transport Profile (SR-TP) networks and defines a
mechanism to create the bi-directional SR tunnel in SR-TP 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 February 28, 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 February 28, 2019 [Page 1]
Internet-Draft PCEP extensions for SR-TP August 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. The SR-TP Architecture with PCE . . . . . . . . . . . . . . . 3
2.1. SR Path SID . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Bi-directional SR tunnel . . . . . . . . . . . . 4
3.1. Associated Bidirectional SR tunnel . . . . . . . . . . . 4
4. PCEP extensions for SR-TP . . . . . . . . . . . . . . . . . . 5
4.1. SR-TP ERO extension . . . . . . . . . . . . . . . . . . . 5
4.2. Processing Rules . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Informative References . . . . . . . . . . . . . . . . . 7
8.2. Normative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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
(SR-TP) network. It is required to extend the PCEP protocol to meet
the new requirements for SR-TP. 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 (SR-TP) networks and defines a
mechanism to create the bidirectional SR tunnel in SR-TP 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 February 28, 2019 [Page 2]
Internet-Draft PCEP extensions for SR-TP August 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-TP Architecture with PCE
As described in [I-D.hu-spring-sr-tp-use-case], in SR-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-TP 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-TP Architecture with PCE
Quan Xiong, et al. Expires February 28, 2019 [Page 3]
Internet-Draft PCEP extensions for SR-TP August 2018
It is required to support bidirectional tunnel to meet the
requirement of SP-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
[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.
3. Overview of 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.
3.1. Associated Bidirectional SR tunnel
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
Quan Xiong, et al. Expires February 28, 2019 [Page 4]
Internet-Draft PCEP extensions for SR-TP August 2018
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 LSPs of the SR tunnel are initiated with the
Association Type set to "Double-sided Bidirectional LSP Association"
and the "Bidirectional LSP Association Group TLV" carried in initial
messages.
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.
4. PCEP extensions for SR-TP
4.1. SR-TP 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 SP-TP
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.
Quan Xiong, et al. Expires February 28, 2019 [Page 5]
Internet-Draft PCEP extensions for SR-TP August 2018
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
The format of Path Label information is specified as
[I-D.cheng-spring-mpls-path-segment].
4.2. 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 Initiate Request
message (PCInitiate).
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 PCInitiate message with the labels in
SR-ERO subobjects, they may forward the packets from bi-directional
tunnel in SR-TP networks.
5. Security Considerations
TBD.
6. IANA Considerations
TBD.
7. Acknowledgements
TBD.
Quan Xiong, et al. Expires February 28, 2019 [Page 6]
Internet-Draft PCEP extensions for SR-TP August 2018
8. References
8.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.
8.2. Normative References
[I-D.cheng-spring-mpls-path-segment]
Cheng, W., Wang, L., Li, H., Chen, M., Zigler, R., Zhan,
S., and R. Gandhi, "Path Segment in MPLS Based Segment
Routing Network", draft-cheng-spring-mpls-path-segment-02
(work in progress), July 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-12 (work in progress), June
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>.
[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>.
Quan Xiong, et al. Expires February 28, 2019 [Page 7]
Internet-Draft PCEP extensions for SR-TP August 2018
[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
Shuangping Zhan
ZTE Corporation
Liuxian Rd
Shenzhen 518057
China
Phone: +86 755 26773770
Email: zhan.shuangping@zte.com.cn
Quan Xiong, et al. Expires February 28, 2019 [Page 8]