<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-han-mpls-sdi-sr-05" ipr="trust200902">
  <front>
    <title abbrev="draft-han-mpls-sdi-sr-01">Signal Degrade Indication in
    Segment Routing over MPLS Network</title>

    <author fullname="Liuyan Han" initials="L." surname="Han">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <region>Beijing</region>

          <country>China</country>
        </postal>

        <email>hanliuyan@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Fan Yang" initials="F." surname="Yang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <country>China</country>
        </postal>

        <email>shirley.yangfan@huawei.com</email>
      </address>
    </author>

    <author fullname="Ren Tan" initials="R." surname="Tan">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <country>China</country>
        </postal>

        <email>tanren@huawei.com</email>
      </address>
    </author>

    <author fullname="Junfeng Zhao" initials="J." surname="Zhao">
      <organization>CAICT</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <country>China</country>
        </postal>

        <email>zhaojunfeng@caict.ac.cn</email>
      </address>
    </author>

    <date day="27" month="December" year="2023"/>

    <workgroup>MPLS Working Group</workgroup>

    <keyword>Signal Degrade Indication, Segment Routing, SR</keyword>

    <abstract>
      <t>This document describes a typical use case of MPLS-TP, where signal
      degrade defect needs to be correctly detected and transmitted via OAM
      messages within network. When MPLS-TP evolves to Segment Routing MPLS,
      transit node has no knowledge of labels to be encapsulated in MPLS label
      stack. Transit node cannot spread OAM messages with signal degrade
      defect indication. Thus, a solution is proposed in this draft.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Background">
      <t>In early era of telecommunication, transport network is set up to
      provide voice service. The connection in network is always
      connection-oriented and circuit switching. With the rapid increasing
      bandwidth brought by Ethernet, transport network transforms into the
      packet-switched transport network. Technologies like MPLS/PWE3 perfectly
      meet the requirements of supporting both packet-transport and
      circuit-transport. It led to the work of MPLS Transport Profile
      (MPLS-TP), collaborated between ITU-T and IETF at the first decade of
      the 21st century.</t>

      <t>MPLS-TP is a subset of MPLS. Features that are not applicable to
      transport network are excluded, and features to meet the requirements of
      transport network, e.g., bidirectional path, deterministic control and
      management, etc., are strictly required. According to the Joint Working
      Team consensus, any extension of MPLS-TP would be included in MPLS
      field.</t>

      <t>With the emerge of Segment Routing (SR) and Software Defined Network
      (SDN), MPLS-TP network technologies are adapted as well. In this draft,
      we recognize one use case where the signal degrade defect can be
      correctly detected and transmitted via MPLS-TP OAM in MPLS-TP, but not
      fulfilled in SR-MPLS. To fix this problem is the motivation of this
      draft.</t>

      <t>Editor's note: This section gives a historical introduction of
      MPLS-TP, since it has been extensively deployed in packet switched
      transport networks for years. The intention of this section is to help
      readers understand the unique of requirements from packet transport
      network. Once the draft becomes RFC, part of this section can be moved
      to Appendix.</t>
    </section>

    <section title="Terminology">
      <t>MPLS: MultiProtocol Label Switching</t>

      <t>PWE3: Pseudo Wire Emulation Edge to Edge</t>

      <t>MPLS-TP: MultiProtocol Label Switching - Transport Profile</t>

      <t>SR: Segment Routing</t>

      <t>SDN: Software Defined Network</t>

      <t>OAM: Operation, Administration and Maintenance</t>

      <t>SD: Signal Degrade</t>

      <t>BER: Bit Error Rate</t>

      <t>WDM: Wavelength Division Multiplexing</t>

      <t>NMS: Network Management System</t>

      <t>G-ACh: Generic Associated Channel</t>

      <t>PDU: Protocol Data Unit</t>

      <t>CCM: Continuity Check Message</t>

      <t>MEP: Maintenance Entity Group End Point</t>

      <t>MIP: Maintenance Entity Group Intermediate Point</t>

      <t>AIS: Alarm Indication Signal</t>
    </section>

    <section title="Problem Statement">
      <section title="Defect Triggered Procedure">
        <t>Signal Degrade (SD) describes a status of signal associated data
        has degraded and a degraded defect is active. Signal degrade of a
        physical link is usually measured and represented by Bit Error Rate
        (BER) value. Fiber aging, impairment and pollution, optical module
        mismatch or WDM transmission error are the reasons to lead to signal
        degrade. More information about signal degrade can be found in<xref
        target="I-D.yang-mpls-ps-sdi-sr"> </xref>.</t>

        <t>In practice, when physical link degrades in network, signal degrade
        defect is firstly detected and reported by the node. A specific type
        of alarm is generated and sent to Network Management System (NMS) or a
        SDN controller. It is a report to management plane and strongly
        required from perspective of network management. However, the problem
        is the notification to management plane is usually not fast enough to
        assist the network recovery. It may result in hour or even day level
        of service interruption time.</t>

        <t>As mentioned in <xref target="RFC6372"/>, defect may trigger system
        to perform a survivability action, when notification of an issue is
        reported from equipment in a lower layer, system fails to receive an
        OAM continuity check message, or receives of an OAM message reporting
        a failure condition. Similarly, when signal degrade defect is reported
        from the lower layer, e.g. physical layer, local protection mechanism
        can be triggered within the internal system of nodez. In case of
        protection switchover selector is at the source or destination node,
        while the signal degrade is happened at intermediate node, an OAM
        message should be transmitted to notify the degrade condition to the
        nodes actually perform the protection switchover. This action is
        preferred to be triggered by events in the data plane <xref
        target="RFC6372"/>.</t>
      </section>

      <section title="MPLS-TP Solution">
        <t>Generic Associated Channel (G-ACh) <xref target="RFC5586"/> is
        defined to carry OAM messages for MPLS pseudowires, LSPs and sections.
        The Generic Associated Channel format used in MPLS is shown in Figure
        1. By using the generic associated channel and indication of channel
        type, different OAM mechanisms with different formats can be
        encapsulated uniformly as well as independently.</t>

        <t><figure align="center">
            <preamble/>

            <artwork align="center"><![CDATA[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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Label                    | EXP |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             GAL Label (13)            | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version|   Reserved    |         Channel Type          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>

            <postamble>Figure 1 G-ACh Format in MPLS</postamble>
          </figure>In MPLS-TP, ITU-T G.8113.1 <xref target="ITU-T_G.8113.1"/>
        specifies a large set of OAM mechanisms and has been widely deployed
        in packet transport networks. Figure 2 shows the common OAM PDU format
        of different OAM mechanisms.</t>

        <t><figure align="center">
            <preamble/>

            <artwork align="center"><![CDATA[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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEL | Version |    OpCode     |     Flags     |  TLV Offset   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           OAM PDU                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|End TLV|
+-+-+-+-+]]></artwork>

            <postamble>Figure 2 ITU-T G.8113.1 Common OAM PDU
            Format</postamble>
          </figure>MEG Level: MEG Level is a 3-bit field. It contains an
        integer value that identifies the MEG level of OAM PDU. Value ranges
        from 0 to 7.</t>

        <t>Version: Version is a 5-bit field. It contains an integer value
        that identifies the OAM protocol version. Value is 0 in the current
        version.</t>

        <t>OpCode: OpCode is a 1-octet field. It contains an OpCode that
        identifies an OAM PDU type. OpCode is used to identify the remaining
        content of an OAM PDU. Value for the CCM PDU type is 1.</t>

        <t>Flags: Flags is an 8-bit field. Use of the bits in this field is
        dependent on the OAM PDU type.</t>

        <t>TLV Offset: TLV Offset is a 1-octet field. It contains the offset
        to the first TLV in an OAM PDU relative to the TLV Offset field. The
        value of this field is associated with an OAM PDU type. When the TLV
        Offset is 0, it points to the first octet following the TLV Offset
        field.</t>

        <t>End TLV: an all-ZEROes octet value.</t>

        <t>When signal degrade happens in MPLS-TP, an MPLS-TP Alarm Indication
        Signal (AIS) OAM message with active AIS indication is generated and
        transmitted within the OAM maintenance domain. Maintenance Entity
        Group End Point (MEP), usually also acting as protection switchover
        selector, performs the protection switchover once it receives the AIS
        indication in MPLS-TP OAM message.</t>
      </section>

      <section title="Problem in SR-MPLS ">
        <t>When Segment Routing is introduced to MPLS, the nodes except the
        headend have no information of the forwarding path. If the signal
        degrade is happened on the transit nodes, MPLS-TP AIS OAM message
        cannot be generated because this node has no knowledge of labels ought
        to be encapsulated in MPLS label stack. Either the label information
        of forwarding path can be obtained on transit node, or the defect can
        be indicated in different messages could help the defect spread in
        network. It is valuable to keep transit node with the capability of
        reporting defects in SR-MPLS.</t>
      </section>
    </section>

    <section title="Solution in SR-MPLS">
      <t>Segment routing is designed to reduce the states in transit nodes,
      any defects like SD defect cannot be indicated in a newly generated OAM
      message on transit node. Alternative way is to indicate the defect in
      other OAM messages. Continuity Check Message (CCM) is proposed to
      indicate the signal degrade defect for two reasons. Firstly, CCM is
      designed to be applicable for fault management, performance monitoring,
      or protection switching applications. Secondly, consider the merit of
      CCM's various transmission period, the defect indication can be flexibly
      transmitted according to operator's needs.</t>

      <t>One reservation bits in Flag section in CCM OAM PDU message can be
      used as Error Indication (EI) to indicate signal degrade. Flag format
      with EI extension is shown in Figure 3.</t>

      <t><figure align="center">
          <preamble/>

          <artwork align="center"><![CDATA[MSB                           LSB
  0
  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|RDI| EI| Reserved  |  Period   |
+---+---+---+---+---+---+---+---+]]></artwork>

          <postamble>Figure 3 CCM OAM PDU Flags Format with EI
          Extension</postamble>
        </figure>RDI: Remote Defect Indication, set to 1 to indicate RDI,
      otherwise it is set to 0.</t>

      <t>Period: Indicate the transmission period.</t>

      <t>EI: Error indication, 0 indicates no error, 1 indicates error.</t>

      <t>Reserved: Reserved fields are set to all ZEROes.</t>

      <t>If the node detects the signal degrade defect, EI field is set in CCM
      OAM message and transmitted to other nodes. Note that, Maintenance
      Entity Group Intermediate Point (MIP) is required to be transparent to
      CCM message in MPLS-TP. In order to support BER indication on each node
      along the forwarding path, extra configuration and intervening
      implementation to process CCM message would be required on MIP.</t>

      <t>Editor's Note: When other OAM mechanisms used in generic associated
      channel (G-ACh), there might be various solutions to transmit signal
      degrade defect, or any other defects detected by transit nodes. This
      draft introduces a very light-weight solution, which has already been
      implemented and deployed in networks.</t>
    </section>

    <section title="IANA Considerations">
      <t>This document requests IANA to assign one bit from Flags of MPLS-TP
      OAM PDU format to indicate "Signal Degrade".</t>
    </section>

    <section title="Security Considerations">
      <t>There are MEP and MIP node defined in OAM mechanisms. Some types of
      OAM message are defined to be transparent to MIP node, and requires no
      extra configuration or message processing on MIP nodes. If the transit
      node of SR-MPLS acts as MIP in OAM maintenance domain, this MIP node
      needs to process the OAM messages to indicate the defects. At the
      moment, explicit configuration is required on MIP to have the authority
      to process OAM messages.</t>
    </section>

    <section title="Acknowledgements">
      <t>The authors want to thank Yuanlong Jiang, Mach Chen, Yongjian Hu for
      their valuable suggestions during the construction of draft.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.yang-mpls-ps-sdi-sr'?>

      <?rfc ?>

      <?rfc include='reference.RFC.6372'?>

      <?rfc include='reference.RFC.5586'?>

      <?rfc ?>

      <reference anchor="ITU-T_G.8113.1">
        <!-- the following is the minimum to make xml2rfc happy -->

        <front>
          <title>G.8113.1: Operations, administration and maintenance
          mechanisms for MPLS-TP in packet transport networks</title>

          <author fullname="ITU-T">
            <organization>ITU-T</organization>
          </author>

          <date month="April" year="2016"/>
        </front>

        <seriesInfo name="" value=""/>
      </reference>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>
    </references>
  </back>
</rfc>
