Internet DRAFT - draft-yang-mpls-ps-sdi-sr
draft-yang-mpls-ps-sdi-sr
MPLS Working Group F. Yang
Internet-Draft Huawei Technologies
Intended status: Informational L. Han
Expires: May 6, 2021 China Mobile
J. Zhao
China Academy of Information Communications Technology
November 2, 2020
Problem Statement of Signal Degrade Indication for SR over MPLS
draft-yang-mpls-ps-sdi-sr-01
Abstract
This document outlines the problem statements and the use cases
needed to be taken into account when the signal degrade is detected
and indicated in Segment Routing (SR) over MPLS networks.
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
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 6, 2021.
Copyright Notice
Copyright (c) 2020 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
Yang, et al. Expires May 6, 2021 [Page 1]
Internet-Draft November 2020
(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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement and Use Case . . . . . . . . . . . . . . . 3
3.1. Overview of Signal Degrade in SR over MPLS Network . . . 3
3.2. Influence on Voice and Data Service . . . . . . . . . . . 4
3.3. Engineering Considerations . . . . . . . . . . . . . . . 4
3.3.1. Signal Degrade in Diversity of PHYs . . . . . . . . . 4
3.3.2. Performance Management Detection . . . . . . . . . . 4
3.3.3. BFD Detection . . . . . . . . . . . . . . . . . . . . 5
3.4. LER and LSR Consideration . . . . . . . . . . . . . . . . 5
3.5. Signal Degrade Approach . . . . . . . . . . . . . . . . . 5
3.6. Parameter Threshold . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Signal Failure (SF) and Signal Degrade (SD) are categorized as the
trigger to bring the survivability challenge to the network in
[RFC4428]. Signal Failure (SF) can be interpreted as the absence of
the network resources, and Signal Degrade (SD) can be regarded as the
decrease of the signal quality quantifiable measurement. The
meanings of signal failure is straightforward, indicating the failure
of the interfaces, links or nodes. Meanwhile, fiber aging, fiber
impairment, fiber pollution, optical module mismatch or WDM
transmission error are the potential reasons to generate signal
degrade.
Segment Routing(SR) leverages the source routing paradigm. In the
era of source routing paradigm, Segment Routing over MPLS (SR-MPLS)
[RFC8402] has been widely utilized for different kinds of network
scenarios. It is valuable to investigate the necessity of supporting
detection of Signal Degrade (SD) in the source routing paradigm.
Yang, et al. Expires May 6, 2021 [Page 2]
Internet-Draft November 2020
This document gives the problem statements for the Signal Degrade
indication and advertisement in the networks of SR over MPLS (SR-
MPLS). The triggered protection mechanism is irrelevant to Signal
Degrade indication and consequently is out of scope.
2. Terminology
SD: Signal Degrade
PLR: Packet Loss Rate
SLA: Service Level Agreement
FEC: Forwarding Error Correction
BFD: Bidirectional Forwarding Detection
3. Problem Statement and Use Case
3.1. Overview of Signal Degrade in SR over MPLS Network
+-----+ +-----+
+-------|LSR1 |-----|LSR2 |------+
| +-----+ +-----+ |
| \ / |
| \ / |
+-----+ +-----+ +-----+
-----|LER1 | |LSR5 | |LER2 |-----
+-----+ +-----+ +-----+
| / \ |
| / \ |
| +-----+ +-----+ |
+-------|LSR3 |-----|LSR4 |------+
+-----+ +-----+
Figure 1: Overview of Signal Degrade in SR over MPLS Network
Figure 1 depicts the overview of the signal degrade detection in the
segment routing over MPLS network. LER1 and LER2 are the Label Edge
Routers, and LSR1 to LSR5 are the Label Switching Routers. The
signal degrade can happen at any links in the SR over MPLS network,
not only the links connected to LERs, but also the links between
LSRs. There is no signal degrade is defined in the current OAM
[I-D.ietf-spring-sr-oam-requirement] or BFD
[I-D.ali-spring-bfd-sr-policy] mechanisms designed for SR over MPLS
network.
Yang, et al. Expires May 6, 2021 [Page 3]
Internet-Draft November 2020
3.2. Influence on Voice and Data Service
In mobile backhaul network, signal degrade may not lead to service
interruption, however it impairs the services and dissatisfies the
Service Level Agreements (SLAs). Take VoLTE service as an example,
signal degrade over the optical transmission can bring noise, carton,
call delay, drop line or even cause base station disconnection. In
addition, the download speed of data service would decrease
dramatically when signal degrade increases. There are some
statistics captured from live network shown in Table 1.
+------------------+---------------------------+
| Packet Loss Rate | Decrease of Download Rate |
+------------------+---------------------------+
| 0 | No affect |
| <0.01% | No affect |
| 0.05% | 23% |
| 0.2% | 58% |
| 1% | 75% |
+------------------+---------------------------+
Table 1 Relation between Packet Loss Rate and Decrease of Download
Rate
3.3. Engineering Considerations
3.3.1. Signal Degrade in Diversity of PHYs
From the perspective of engineering, there are a variety of PHYs
defined in IEEE 802.3. The PHYs without Forward Error Correction
(FEC) generates the defects/alarms, PHYs with the FEC correct the bit
errors. There is no uniform mechanism to guarantee the control of
the bit errors.
3.3.2. Performance Management Detection
The approaches of OAM performance management can be used as the tools
to detect the signal degrade. On one hand, active performance
management cannot fulfill the Signal Degrade detection all the time.
On the other hand, passive performance management consumes too much
resource of the equipment so that operators can hardly use it in the
networks. The current performance management mechanism is not
feasible to detect signal degrade conveniently and efficiently.
Yang, et al. Expires May 6, 2021 [Page 4]
Internet-Draft November 2020
3.3.3. BFD Detection
For the worst case, when signal degrade happens on LSRs, the current
best practice is to make use of the result of BFD protocol on LERs to
trigger the protection mechanism. The detection time is at least
3.3ms*3 later than the time when the signal degrade happens. If the
LSRs can trigger the protection protocol in a more direct and
efficient way, the network service interruption time can be reduced.
3.4. LER and LSR Consideration
There are local and remote request logics about the signal degrade
defined in [RFC6378]. Meanwhile, the Protection State Coordination
(PSC) process and the messages are utilized to advertise and exchange
the signal degrade state between LERs. In the network of MPLS-TP,
the LSRs stay dumb in the transmission of OAM messages.
In the SR over MPLS networks, only the headend LER knows all the
segments in the label stack, the other LSRs and LER2 does not know
the entire label stack. As for the signal degrade happens on either
headend LER or other LSRs and LER, the mechanism of the signal
degrade indication would be differently designed.
3.5. Signal Degrade Approach
In Section 4.1 of [RFC6372], approaches of detection or recognition
of network defect such as signal degrade are specified. The signal
degrade indication can be detected from a network defect, or
advertised by an in-band data-plane-based OAM mechanism, or by in-
band or out-of-band control-plane signaling, or triggered from the
centralized Network Management System (NMS) or a SDN controller. The
appropriate approaches should be wisely selected.
3.6. Parameter Threshold
Parameters like BER or PLR are the different quantitative measurement
methods. It is flexible for the service providers to set different
values of threshold based on the geographical site investigations.
For an even more complicated scenario, the threshold may be defined
differently in terms of services, for example to differentiate the
requirements of the eMBB or URLLC applications in 5G era.
4. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Yang, et al. Expires May 6, 2021 [Page 5]
Internet-Draft November 2020
5. Security Considerations
This document has no consideration of security.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Acknowledgements
TBD
7. References
7.1. Normative References
[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>.
7.2. Informative References
[I-D.ali-spring-bfd-sr-policy]
Ali, Z., Talaulikar, K., Filsfils, C., Nainar, N., and C.
Pignataro, "Bidirectional Forwarding Detection (BFD) for
Segment Routing Policies for Traffic Engineering", draft-
ali-spring-bfd-sr-policy-05 (work in progress), May 2020.
[I-D.ietf-spring-sr-oam-requirement]
Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
and S. Litkowski, "OAM Requirements for Segment Routing
Network", draft-ietf-spring-sr-oam-requirement-03 (work in
progress), January 2017.
[RFC4428] Papadimitriou, D., Ed. and E. Mannie, Ed., "Analysis of
Generalized Multi-Protocol Label Switching (GMPLS)-based
Recovery Mechanisms (including Protection and
Restoration)", RFC 4428, DOI 10.17487/RFC4428, March 2006,
<https://www.rfc-editor.org/info/rfc4428>.
[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
Profile (MPLS-TP) Survivability Framework", RFC 6372,
DOI 10.17487/RFC6372, September 2011,
<https://www.rfc-editor.org/info/rfc6372>.
Yang, et al. Expires May 6, 2021 [Page 6]
Internet-Draft November 2020
[RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher,
N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-
TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378,
October 2011, <https://www.rfc-editor.org/info/rfc6378>.
[RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H.,
D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS
Transport Profile (MPLS-TP) Linear Protection to Match the
Operational Expectations of Synchronous Digital Hierarchy,
Optical Transport Network, and Ethernet Transport Network
Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014,
<https://www.rfc-editor.org/info/rfc7271>.
[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
Fan Yang
Huawei Technologies
Email: shirley.yangfan@huawei.com
Liuyan Han
China Mobile
Email: hanliuyan@chinamobile.com
Junfeng Zhao
China Academy of Information Communications Technology
Email: zhaojunfeng@caict.ac.cn
Yang, et al. Expires May 6, 2021 [Page 7]
