Skip to main content

Path Segment in MPLS Based Segment Routing Network
draft-cheng-spring-mpls-path-segment-02

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 "Replaced".
Authors Weiqiang Cheng , Lei Wang , Han Li , Mach Chen , Royi Zigler , Shuangping Zhan , Rakesh Gandhi
Last updated 2018-07-02 (Latest revision 2018-03-05)
Replaced by draft-ietf-spring-mpls-path-segment, draft-ietf-spring-mpls-path-segment
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-cheng-spring-mpls-path-segment-02
Network Working Group                                           W. Cheng
Internet-Draft                                                   L. Wang
Intended status: Standards Track                                   H. Li
Expires: January 3, 2019                                    China Mobile
                                                                 M. Chen
                                                                  Huawei
                                                               R. Zigler
                                                                Broadcom
                                                                 S. Zhan
                                                                     ZTE
                                                               R. Gandhi
                                                     Cisco Systems, Inc.
                                                           July 02, 2018

           Path Segment in MPLS Based Segment Routing Network
                draft-cheng-spring-mpls-path-segment-02

Abstract

   An SR path is identified by an SR segment list, one or partial
   segments of the list cannot uniquely identify the SR path.  Path
   identification is the precondition of performance measurement (PM) of
   an 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.

   Path segment can be used by the egress node to implement path
   identification hence to support SR path PM, end-2-end SR path
   protection and bidirectional SR paths correlation.

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

Cheng, et al.            Expires January 3, 2019                [Page 1]
Internet-Draft           Path Segment in SR-MPLS               July 2018

   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 January 3, 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Path Segment  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  One Label Solution  . . . . . . . . . . . . . . . . . . .   3
     2.2.  Two Labels Solution . . . . . . . . . . . . . . . . . . .   5
   3.  Path Segment Allocation . . . . . . . . . . . . . . . . . . .   6
   4.  Path Segment based PM . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Direct Packet Loss Measurement  . . . . . . . . . . . . .   7
     4.2.  Indirect Packet Loss Measurement  . . . . . . . . . . . .   7
     4.3.  Packet Delay Measurement  . . . . . . . . . . . . . . . .   8
   5.  Path Segment for Bi-directional SR Path . . . . . . . . . . .   8
   6.  Path Segment based End-2-end Path Protection  . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   9
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     11.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

Cheng, et al.            Expires January 3, 2019                [Page 2]
Internet-Draft           Path Segment in SR-MPLS               July 2018

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

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 preferred.  There some discussions on the mailing list
   show that the one label solution is preferred.]

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.

Cheng, et al.            Expires January 3, 2019                [Page 3]
Internet-Draft           Path Segment in SR-MPLS               July 2018

   The value of the TTL field of the Path label MUST be set to the same
   value of the last segment label of the SR path.  If the Path label is
   the bottom label, the S bit MUST be set.  How to set to the TC field
   is up to the specific use case of Path segment.

   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 an error
   situation.

   The egress node MUST pop the Path label and deliver it to relevant
   components for further processing.  For example, when performance
   measurement is enabled on the SR path, it will trigger packet
   counting or timestamping.

   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.

Cheng, et al.            Expires January 3, 2019                [Page 4]
Internet-Draft           Path Segment in SR-MPLS               July 2018

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 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):

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

Cheng, et al.            Expires January 3, 2019                [Page 5]
Internet-Draft           Path Segment in SR-MPLS               July 2018

      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 TTL field of the Source Label MUST be set to the same
      values as the label (e.g., the Label n) it follows.  How to set to
      TC field is up to the specific use case of Path segment.

   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.

3.  Path Segment Allocation

   Several ways can be used to assign the Path Segment.

   One way is that to set up a communication channel (e.g., MPLS Generic
   Associated Channel (G-ACh)) between the ingress node and the egress
   node and the ingress node of the SR path can directly send a request
   to the egress node to ask for a Path label.

   Another candidate way is to leverage a centralized controller (e.g.,
   PCE, SDN controller) to assign the Path label.  PCEP based Path
   Segment allocation is defined in [I-D.li-pce-sr-path-segment], and
   SR-policy based path segment allocation is defined in
   [I-D.li-idr-sr-policy-path-segment-distribution].

4.  Path Segment based PM

   Path segment is mainly for packet loss measurement, but it can also
   apply to packet delay measurement.

Cheng, et al.            Expires January 3, 2019                [Page 6]
Internet-Draft           Path Segment in SR-MPLS               July 2018

4.1.  Direct Packet Loss Measurement

   Measuring packet loss of real traffic is called "direct mode" packet
   loss measurement in [RFC6374].  To measure the packet loss 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.  At the egress node, since the path
   label (or combination with Source label) can be used to identify the
   path, path based packet counting can be implemented as well.  Once
   get the counts on ingress and egress node, packet loss can be
   calculated.

   [RFC6374] defines Loss Measurement Message to comunicate the counts
   between ingress and egress nodes.  [I-D.gandhi-spring-sr-mpls-pm]
   reviews how mechanisms defined in [RFC6374] can be used for packet
   Delay Measurement (DM) and Loss Measurements (LM) in SR networks with
   MPLS data plane.  [I-D.gandhi-spring-udp-pm] specifies a procedure
   for using UDP path for sending and processing in-band probe query and
   response messages for packet loss and delay measurement.

   The "direct mode" for loss measurement defined in [RFC6374] assumes
   that there is no packet misordering, otherwise it will degrade the
   accuracy of the packet loss measurement.  So, for the case where this
   is no packet misordering, the direct packet losss measurment defined
   in [RFC6374] can be used.

   [RFC8321] introduces an Alternate-Marking (coloring) based mechanism
   to perform packet loss, delay, and jitter measurements on real
   traffic.  For packet loss measurement, since it only depends on the
   marker (color) on each packet to differentiate to which block/batch
   the packet belong, packet misordering will not affect the accuracy of
   the packet loss measurement.

   How to apply Alternate-Marking based mechanism [RFC8321] to measure
   performance of an SR path will added in next revision.

4.2.  Indirect Packet Loss Measurement

   As defined in [RFC6374], indirect packet loss measurement is to
   measure the packet loss of the injected OAM probing packets, hence to
   mimc the performance of a path.  For indirect packet loss
   measurement, path identification is also needed.  But compare to the
   direct packet loss measurement, the path segment can be carried in
   the SR label stack (just as described in Section 2 of this document),
   or be directly carried in the Loss Measurement Message (e.g., a new
   TLV).  The detail of how path segment is carried in the Loss
   Measurement Message will be defined in future version.

Cheng, et al.            Expires January 3, 2019                [Page 7]
Internet-Draft           Path Segment in SR-MPLS               July 2018

4.3.  Packet Delay Measurement

   More detail will be added in next revision.

5.  Path Segment for Bi-directional SR Path

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

   [I-D.li-pce-sr-path-segment] defines how to use PCEP to initiate a
   bidirectional SR path, and
   [I-D.li-idr-sr-policy-path-segment-distribution] defines how to use
   SR policy to initiate a bidirectional SR path.

6.  Path Segment based 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

Cheng, et al.            Expires January 3, 2019                [Page 8]
Internet-Draft           Path Segment in SR-MPLS               July 2018

   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.

7.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

8.  Security Considerations

9.  Contributors

   The following individuals also contribute to this document.

   o  Shuangping Zhan, ZTE

   o  Cheng Li, Huawei

10.  Acknowledgements

   The authors would like to thank Stewart Bryant for his review,
   suggestion and comments to this document.

11.  References

11.1.  Normative References

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
              d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
              (SRH)", draft-ietf-6man-segment-routing-header-14 (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>.

11.2.  Informative References

   [I-D.gandhi-spring-sr-mpls-pm]
              Gandhi, R., Filsfils, C., Soni, S., daniel.voyer@bell.ca,
              d., Salsano, S., and P. Ventre, "Performance Measurement
              in Segment Routing Networks with MPLS Data Plane", draft-
              gandhi-spring-sr-mpls-pm-01 (work in progress), June 2018.

Cheng, et al.            Expires January 3, 2019                [Page 9]
Internet-Draft           Path Segment in SR-MPLS               July 2018

   [I-D.gandhi-spring-udp-pm]
              Gandhi, R., Filsfils, C., Soni, S., daniel.voyer@bell.ca,
              d., Salsano, S., and P. Ventre, "UDP Path for In-band
              Performance Measurement for Segment Routing Networks",
              draft-gandhi-spring-udp-pm-01 (work in progress), June
              2018.

   [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-15 (work
              in progress), January 2018.

   [I-D.ietf-spring-segment-routing-mpls]
              Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing with MPLS
              data plane", draft-ietf-spring-segment-routing-mpls-14
              (work in progress), June 2018.

   [I-D.li-idr-sr-policy-path-segment-distribution]
              Li, C., Chen, M., Dong, J., and Z. Li, "Segment Routing
              Policies for Path Segment and Bi-directional Path", draft-
              li-idr-sr-policy-path-segment-distribution-00 (work in
              progress), April 2018.

   [I-D.li-pce-sr-path-segment]
              Li, C., Chen, M., Dong, J., Li, Z., and D. Dhody, "Path
              Computation Element Communication Protocol (PCEP)
              Extension for Path Identification in Segment Routing
              (SR)", draft-li-pce-sr-path-segment-00 (work in progress),
              June 2018.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374,
              DOI 10.17487/RFC6374, September 2011,
              <https://www.rfc-editor.org/info/rfc6374>.

   [RFC8321]  Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
              L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
              "Alternate-Marking Method for Passive and Hybrid
              Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
              January 2018, <https://www.rfc-editor.org/info/rfc8321>.

Authors' Addresses

Cheng, et al.            Expires January 3, 2019               [Page 10]
Internet-Draft           Path Segment in SR-MPLS               July 2018

   Weiqiang Cheng
   China Mobile

   Email: chengweiqiang@chinamobile.com

   Lei Wang
   China Mobile

   Email: wangleiyj@chinamobile.com

   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

   Rakesh Gandhi
   Cisco Systems, Inc.
   Canada

   Email: rgandhi@cisco.com

Cheng, et al.            Expires January 3, 2019               [Page 11]