Network Working Group W. Cheng Internet-Draft L. Wang Intended status: Standards Track H. Li Expires: May 3, 2018 China Mobile M. Chen Huawei R. Zigler Broadcom S. Zhan ZTE October 30, 2017 Path Segment in MPLS Based Sement Routing Network draft-cheng-spring-mpls-path-segment-00 Abstract An SR path is identified by an SR segment list, one or partial segments of the list cannot uniquely identify the SR path. This document introduces the concept of Path Segment that is used to identify an SR path. When used, it is inserted at the ingress node of the SR path and immediately follows the last segment of the SR path. The Path Segment will not be popped off until it reaches the egress of the SR path, it can be used by the egress node to implement end-2-end SR path protection or performance measurement (PM) of an SR path. 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 RFC 2119 [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 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 Cheng, et al. Expires May 3, 2018 [Page 1] Internet-Draft Path Segment in SR-MPLS October 2017 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 May 3, 2018. 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 (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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Path Segment . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. One Label Solution . . . . . . . . . . . . . . . . . . . 3 2.1.1. Path Segment Assignment . . . . . . . . . . . . . . . 4 2.2. Two Labels Solution . . . . . . . . . . . . . . . . . . . 5 3. Path Segment Application . . . . . . . . . . . . . . . . . . 7 3.1. Performance Measurement . . . . . . . . . . . . . . . . . 7 3.2. End-2-end Path Protection . . . . . . . . . . . . . . . . 7 3.3. Bi-directional SR Tunnel . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Segment Routing (SR) [I-D.ietf-spring-segment-routing] is a source routed forwarding method that allows to directly encode forwarding instructions (called segments) in each packet, hence it enables to steer traffic through a network without the per-flow states maintained in the transit nodes. Segment Routing can be instantiated on MPLS data plane or IPv6 data plane. The former is called SR-MPLS Cheng, et al. Expires May 3, 2018 [Page 2] Internet-Draft Path Segment in SR-MPLS October 2017 [I-D.ietf-spring-segment-routing-mpls], the latter is called SRv6 [I-D.ietf-6man-segment-routing-header]. SR-MPLS leverages the MPLS label stack to construct SR path, and SRv6 uses the Segment Routing Header to construct SR path. In an SR-MPLS network, when a packet is transmitted along an SR path, the labels in the MPLS label stack will be swapped or popped. So that no label or only the last label may be left in the MPLS label stack when the packet reaches the egress node. Thus, the egress node cannot determine from which ingress node or SR path the packet comes. However, to support use cases like end-2-end 1+1 path protection, bidirectional path correlation or performance measurement(PM), the ability to implement path identification is the pre-condition. Therefore, this document introduces a new segment that is referred to as Path Segment. A Path Segment is defined to unique identify an SR path in a specific context. (e.g., in the context of the egress node or ingress node of an SR path, or within an SR domain). It is normally used by egress nodes for path identification or correlation. Path Segment can only apply to SR-MPLS. 2. Path Segment This document introduces two options for SR path identification: one label solution and two labels solution. [Editor notes: it is supposed that the WG will discuss and decide which one is the better solution.] 2.1. One Label Solution The Path Segment is a single label that is assigned from the Segment Routing Local Block (SRLB) or Segment Routing Global Block (SRGB) of the egress node of an SR path. It means that the Path Segment is unique in the context of the egress node of SR paths. When Path Segment is used, a Path label MUST be inserted at the ingress node and MUST immediately follow the last label of the SR path. If the Path label is the bottom label, the S bit MUST be set. The value of the TC field MUST be set to the same value as the last segment label of the SR path. The value of the TTL field MUST be set to the same value of the last segment label of the SR path. Normally, the intermediates node will not see the Path Segment label and do not know how to process it even if they see it. A Path Segment label presenting to an intermediate node is error situation. Cheng, et al. Expires May 3, 2018 [Page 3] Internet-Draft Path Segment in SR-MPLS October 2017 The egress node MUST pop the Path label and deliver it to relevant components for further processing. The label stack with Path Segment is as below (Figure1): +--------------------+ | ... | +--------------------+ | Label 1 | +--------------------+ | Label 2 | +--------------------+ | ... | +--------------------+ | Label n | +--------------------+ | Path Label | +--------------------+ | ... | +--------------------+ Figure 1: Label Stack with Path Segment Where: o The Label 1-n are the segment labels that are used to direct how to steer the packets along the SR path. o The Path Label identifies the SR path in the context of the egress node of the SR path. 2.1.1. Path Segment Assignment Several ways can be used to assign the Path Segment. One way is that the Path Segment label is directly assigned by the egress node of an SR path. Where the ingress node of the SR path can directly send a request to the egress node to ask for a Path label. With this way, it needs to set up a communication channel between the ingress node and the egress node. New protocols or extensions to existing protocol may be required. Another candidate way is to leverage a centralized controller (e.g., PCE) to assign the Path label. The ingress node sends a request to the PCE to compute a SR path and indicate that a Path label is desired. The PCE will compute the path as required. Once the path computed, the PCE will send a request (with computed path and relevant information) to the egress node to ask for a Path label for Cheng, et al. Expires May 3, 2018 [Page 4] Internet-Draft Path Segment in SR-MPLS October 2017 the SR path. The egress node will allocate a label to the SR path and build mapping relationship between the label and the path. A reply will be sent back to the PCE, the PCE will send a reply to the ingress node about the path information and the corresponding Path Segment label. With either way or the variations, the final purpose is to assign a label from the egress node's label space, hence a single label is enough for path identification. Then the ingress node can put the Path Segment label into the label stack when needed, and the egress node can use that Path Segment to implement relevant functionalities. 2.2. Two Labels Solution Two segments (Source segment and Path segment) are used to identify an SR path. The Source segment is a global node segment, it can uniquely identify a node within an SR domain. It MUST NOT be used for forwarding and indicates that a Path segment immediately follows. The Path segment is a local segment generated at the ingress node to identify an SR path. The combination of Source segment and Path segment can uniquely identify an SR Path with an SR domain. A node that enables Path segment function will be assigned two node segments. One is for forwarding just as defined in [I-D.ietf-spring-segment-routing], the other is for source identification. The corresponding label of the Source Segment is indexed in the SRGB (or in a of the node to which the Source Segment will be presented. The Path segment label is a local label that is assigned to an SR path at the ingress node. The label stack with Source and Path segments is as below (Figure 2): Cheng, et al. Expires May 3, 2018 [Page 5] Internet-Draft Path Segment in SR-MPLS October 2017 +--------------------+ | ... | +--------------------+ | Label 1 | +--------------------+ | Label 2 | +--------------------+ | ... | +--------------------+ | Label n | +--------------------+ | Source Label | +--------------------+ | Path Label | +--------------------+ | ... | +--------------------+ Figure 2: Label Stack with Source and Path Segments Where: o The Label 1-n are the segment labels that are used to direct how to steer the packets along an SR path, and the "label n" is the last label of the SR path or the label that directs forwarding packets to the node to which the Source Segment will be presented. o The Source Label identifies the source of the SR path. The value of the TC and TTL fields of the Source Label MUST be set to the same values as the label (e.g., the Label n) it follows. o The Path Label identifies the SR path in the context of source node. If the Path label is the bottom label, the S bit MUST be set. The value of the TC and TTL fields SHOULD be set to the same values as the Source label. The Source and Path label MUST be inserted at the ingress node of an SR path. And they MUST immediately follow the label that directs forwarding packets to the node (e.g., the egress or an intermediate node) to which the Source Segment (as the stack top label) and Path Segment are presented. If a node receives a packet with an unknown Source Label, the packet MUST be discarded and an error SHOULD be reported. The Source label and Path label MUST be popped at the node who receives a packet with the Source label as the stack top label. Cheng, et al. Expires May 3, 2018 [Page 6] Internet-Draft Path Segment in SR-MPLS October 2017 3. Path Segment Application 3.1. Performance Measurement To measure the packet loss and delay of the real traffic of an SR path, one fundamental condition is path identification at the measuring points. For an SR path, the ingress node have the complete information of the path, it can use those information for packet counting and/or timestamping. At the egress node, since the Path Segment label (or combination with Source label) can be used to identify the path, path based packet counting and/or timestamping can be implemented as well. Then combined with the mechanisms defined [RFC6374], end-2-end packet loss and/or delay measurement of an SR path can be achieved. Measuring at intermediate nodes needs more consideration, it will be added in the next version. 3.2. End-2-end Path Protection For end-2-end 1+1 path protection, the egress node of an path needs to know the set of paths that constitute the primary and the backup(s), in order to select the primary packet for onward transmission, and to discard the packets from the backups. To do this each path needs a path identifier that is unique at the egress node. Depending on the design, this single unique label chosen by the egress PE or the combination of the source node identifier and a unique path identifier chosen by the source. There then needs to be a method of binding this path identifiers into equivalence groups such that the egress PE can determine the set of packets that represent a single path and its backup. It is obvious that this group can be instantiated in the network by an SDN controller. In a network that is using a distributed control plane the approach will depend on the control protocol used, but the essence of the solution is that which ever PE is responsible for creating the group advertises then as a group of equivalent paths. Whether one of these is advertised as primary and the others as secondary will or all are advertised as of equal status will depend on the details of the underlying protection mechanism. Cheng, et al. Expires May 3, 2018 [Page 7] Internet-Draft Path Segment in SR-MPLS October 2017 3.3. Bi-directional SR Tunnel With the current SR architecture, an SR path is an unidirectional path. In some scenarios, for example, mobile backhaul transport network, there are requirements to support bi-directional path, and the path is normally treated as a single entity and both directions of the path have same fate, for example, failure in one direction will result in switching at both directions. MPLS supports this by introducing the concepts of co-routed bidirectional LSP and associated bi-directional LSP. With SR, to support bidirectional path, a straightforward way is to bind two unidirectional SR paths to a single bi-directional path. Path segments can be used to correlate the two unidirectional SR paths at both ends of the paths. 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations 6. Contributors The following individuals also contribute to this document. o Shuangping Zhan, ZTE o Cheng Li, Huawei 7. Acknowledgements The authors would like to thank Stewart Bryant for his review, suggestion and comments to this document. 8. References 8.1. Normative References Cheng, et al. Expires May 3, 2018 [Page 8] Internet-Draft Path Segment in SR-MPLS October 2017 [I-D.ietf-6man-segment-routing-header] Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- segment-routing-header-07 (work in progress), July 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 8.2. Informative References [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-13 (work in progress), October 2017. [I-D.ietf-spring-segment-routing-mpls] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", draft-ietf-spring-segment-routing-mpls-10 (work in progress), June 2017. [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, . Authors' Addresses Weiqiang Cheng China Mobile Email: chengweiqiang@chinamobile.com Lei Wang China Mobile Email: wangleiyj@chinamobile.com Cheng, et al. Expires May 3, 2018 [Page 9] Internet-Draft Path Segment in SR-MPLS October 2017 Han Li China Mobile Email: lihan@chinamobile.com Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com Royi Zigler Broadcom Email: royi.zigler@broadcom.com Shuangping Zhan ZTE Email: zhan.shuangping@zte.com.cn Cheng, et al. Expires May 3, 2018 [Page 10]