GMPLS Lock and Loopback: GMPLS RSVP-TE Extensions for Lock Instruct and Loopback
RSVP-TE signaling to lock a GMPLS label switched path and loop traffic back at a chosen node for testing.
Dong, J., Chen, M., Li, Z., and D. Ceccarelli, "GMPLS RSVP-TE Extensions for Lock Instruct and Loopback", RFC 7571, DOI 10.17487/RFC7571, July 2015, <https://www.rfc-editor.org/info/rfc7571>.
@misc{rfc7571,
series = {Request for Comments},
number = 7571,
howpublished = {RFC 7571},
publisher = {RFC Editor},
doi = {10.17487/RFC7571},
url = {https://www.rfc-editor.org/info/rfc7571},
author = {J. Dong and M. Chen and Z. Li and D. Ceccarelli},
title = {{GMPLS RSVP-TE Extensions for Lock Instruct and Loopback}},
pagetotal = 9,
year = 2015,
month = jul,
} RFC text
Contents
Internet Engineering Task Force (IETF) J. Dong
Request for Comments: 7571 M. Chen
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 Z. Li
China Mobile
D. Ceccarelli
Ericsson
July 2015
GMPLS RSVP-TE Extensions for Lock Instruct and Loopback
Abstract
This document specifies extensions to Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and
Loopback (LB) mechanisms for Label Switched Paths (LSPs). These
mechanisms are applicable to technologies that use Generalized MPLS
(GMPLS) for the control plane.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7571.
Copyright Notice
Copyright (c) 2015 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
(http://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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Flag Definitions for LI and LB . . . . . . . . . . . . . . . 3
2.1. Lock Instruct Indication . . . . . . . . . . . . . . . . 3
2.2. Extensions for Loopback . . . . . . . . . . . . . . . . . 3
3. Operational Procedures . . . . . . . . . . . . . . . . . . . 3
3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4.1. Attribute Flags . . . . . . . . . . . . . . . . . . . . . 6
4.2. RSVP Error Value Sub-Codes . . . . . . . . . . . . . . . 6
4.3. Allocation Rule for ERO Subobjects . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The requirements for Lock Instruct (LI) and Loopback (LB) in the
Multiprotocol Label Switching Transport Profile (MPLS-TP) are
specified in [RFC5860], and the framework of LI and LB is specified
in [RFC6371]. A Label Switched Path (LSP) that is locked, using LI,
is prevented from carrying user data traffic. The LB function can
only be applied to an LSP that has been previously locked.
In general, the LI and LB are useful Operations, Administration, and
Maintenance (OAM) functions for technologies that use Generalized
MPLS (GMPLS) for the control plane, e.g., time-division multiplexing,
wavelength-division multiplexing, and packet switching. It is
natural to use and extend the GMPLS control-plane protocol to provide
a unified approach for LI and LB provisioning in all these
technologies.
[RFC7487] specifies the RSVP-TE extensions for the configuration of
proactive MPLS-TP OAM functions, such as Continuity Check (CC),
Connectivity Verification (CV), Delay Measurement (DM), and Loss
Measurement (LM). The provisioning of on-demand OAM functions such
as LI and LB are not covered in that document.
This document specifies extensions to Resource Reservation Protocol-
Traffic Engineering (RSVP-TE) to support lock instruct and loopback
mechanisms for LSPs. The mechanisms are applicable to technologies
that use GMPLS for the control plane. For a network supporting MPLS-
TP, the mechanisms defined in this document are complementary to
[RFC6435].
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 RFC 2119 [RFC2119].
2. Flag Definitions for LI and LB
2.1. Lock Instruct Indication
In order to indicate the lock/unlock status of the LSP, the A
(Administratively down) bit in the Administrative Status
(ADMIN_STATUS) Object [RFC3471] [RFC3473] is used.
2.2. Extensions for Loopback
In order to indicate the loopback mode of LSP, a new bit flag is
defined in the Attribute Flags TLV [RFC5420].
Loopback flag:
This flag indicates a particular node on the LSP is required to
enter loopback mode. This can also be used for specifying the
loopback state of the node.
- Bit number: 13
- Attribute flag carried in Path message: Yes
- Attribute flag carried in Resv message: No
- Attribute flag carried in the Record Route Object (RRO)
Attributes subobject: Yes
3. Operational Procedures
3.1. Lock Instruct
When an ingress node intends to put an LSP into lock mode, it MUST
send a Path message with the Administratively down (A) bit used as
specified above and the Reflect (R) bit in the ADMIN_STATUS Object
set.
On receipt of this Path message, the egress node SHOULD try to take
the LSP out of service. If the egress node locks the LSP
successfully, it MUST send a Resv message with the A bit in the
ADMIN_STATUS Object set. Otherwise, it MUST send a PathErr message
with the Error Code "OAM Problem" [RFC7260] and the new Error Value
"Lock Failure", and the following Resv messages MUST be sent with the
A bit cleared.
When an LSP is put in lock mode, the subsequent Path and Resv
messages MUST keep the A bit in the ADMIN_STATUS Object set.
When the ingress node intends to take the LSP out of the lock mode,
it MUST send a Path message with the A bit in the ADMIN_STATUS Object
cleared.
On receipt of this Path message, the egress node SHOULD try to bring
the LSP back to service. If the egress node unlocks the LSP
successfully, it MUST send a Resv message with the A bit in the
ADMIN_STATUS Object cleared. Otherwise, it MUST send a PathErr
message with the Error Code "OAM Problem" [RFC7260] and the new Error
Value "Unlock Failure", and the following Resv messages MUST be sent
with the A bit set.
When an LSP is taken out of lock mode, the subsequent Path and Resv
messages MUST keep the A bit in the ADMIN_STATUS Object cleared.
3.2. Loopback
The loopback request can be sent either to the egress node or to a
particular intermediate node. The mechanism defined in [RFC7570] is
used for addressing the loopback request to a particular node on the
LSP. The ingress node MUST ensure that the LSP is in lock mode
before it requests setting a particular node on the LSP into loopback
mode.
When an ingress node intends to put a particular node on the LSP into
loopback mode, it MUST send a Path message with the Loopback
Attribute Flag defined above in the Attribute Flags TLV set. The
mechanism defined in [RFC7570] is used to address the loopback
request to the particular node. The ingress node MUST ensure that
the entity at which loopback is intended to occur is explicitly
identified by the immediately preceding subobject of the Explicit
Route Object (ERO) Hop Attributes subobject. The Administratively
down (A) bit in the ADMIN_STATUS Object MUST be kept set to indicate
that the LSP is still in lock mode.
On receipt of this Path message, the target node of the loopback
request MUST check if the LSP is in lock mode by verifying that the
Administratively down (A) bit is set in the ADMIN_STATUS Object. If
the bit is not set, the loopback request MUST be ignored. If the bit
is set, the node MUST check that the desired loopback entity is
explicitly identified by the ERO subobject prior to the ERO Hop
Attributes subobject. Currently, the type value MUST be verified to
be less than 32 (i.e., able to identify a specific entity where a
loopback can occur; see Section 4.3), and for type values 1 (IPv4
prefix) and 2 (IPv6 prefix), the prefix length MUST be 32 and 128,
respectively. If the desired loopback entity is not explicitly
identified, the request MUST be ignored and a "Bad EXPLICIT_ROUTE
object" error SHOULD be generated. Otherwise, the node SHOULD try to
put the LSP into loopback mode. The loopback SHOULD be enabled on
the entity identified by the ERO subobject immediately prior to the
ERO Hop Attributes subobject. If the immediately preceding subobject
is a label subobject [RFC3473], the loopback SHOULD be enabled for
the direction indicated by the U bit of the label subobject.
If the node puts the LSP into loopback mode successfully, it MUST set
the Loopback Attribute Flag if it adds, per [RFC7570], an RRO Hop
Attributes subobject to the RRO of a Path or Resv message. The
Administratively down (A) bit in the ADMIN_STATUS Object MUST be kept
set in the message. If the node cannot put the LSP into loopback
mode, it MUST send a PathErr message with the Error Code "OAM
Problem" [RFC7260] and the new Error Value "Loopback Failure".
When the ingress node intends to take the particular node out of
loopback mode, it MUST send a Path message with the Loopback
Attribute Flag in the Attribute Flags TLV cleared. The mechanism
defined in [RFC7570] is used to indicate that the particular node
SHOULD exit loopback mode for this LSP. The Administratively down
(A) bit in the ADMIN_STATUS Object MUST be kept set to indicate the
LSP is still in lock mode.
On receipt of this Path message, the target node SHOULD try to take
the LSP out of loopback mode. If the node takes the LSP out of
loopback mode successfully, it MUST clear the Loopback Attribute Flag
in the RRO Hop Attributes subobject and push this subobject onto the
RRO object in the corresponding Path or Resv message. The
Administratively down (A) bit in the ADMIN_STATUS Object MUST be kept
set in the message. Otherwise, the node MUST send a PathErr message
with the Error Code "OAM Problem" [RFC7260] and the new Error Value
"Exit Loopback Failure".
After the loopback mode is cleared successfully, the ingress node MAY
remove the Lock Instruct using the mechanism defined in Section 3.1.
The ingress node MUST NOT request to exit lock mode if the LSP is
still in loopback mode. The egress node MUST ignore such a request
when the LSP is still in loopback mode.
4. IANA Considerations
IANA has assigned new values defined in this document and summarized
in this section.
4.1. Attribute Flags
IANA maintains a registry called "Resource Reservation Protocol-
Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called
"Attribute Flags".
IANA has assigned a new bit flag as follows:
Bit | | Attribute | Attribute | | |
No. | Name | Flags Path | Flags Resv | RRO | ERO | Reference
-----+-----------+------------+------------+-----+-----+-------------
13 | Loopback | Yes | No | Yes | Yes |this document
4.2. RSVP Error Value Sub-Codes
IANA maintains a registry called "Resource Reservation Protocol
(RSVP) Parameters" with a sub-registry called "Error Codes and
Globally-Defined Error Value Sub-Codes".
IANA has assigned four new Error Value sub-codes for the "OAM
Problem" Error Code:
Value | Description | Reference
-----------+-----------------------------+--------------
26 | Lock Failure | this document
27 | Unlock Failure | this document
28 | Loopback Failure | this document
29 | Exit Loopback Failure | this document
4.3. Allocation Rule for ERO Subobjects
IANA maintains a registry called "Resource Reservation Protocol
(RSVP) Parameters" with a sub-registry called "Class Names, Class
Numbers, and Class Types".
For Explicit Route Object, the allocation rule for subobject types in
the range 5-31 (0x05 - 0x1F) has been updated as:
5-31 Unassigned (For explicit resource identification)
5. Security Considerations
This document does not introduce any new security issues beyond those
identified in [RFC3209], [RFC3473], and [RFC7570]. For a more
comprehensive discussion of GMPLS security and attack mitigation
techniques, please see "Security Framework for MPLS and GMPLS
Networks" [RFC5920].
In addition, the reporting of the loopback status using the RRO may
reveal details about the node that the operator wishes to remain
confidential. The privacy considerations as described in paragraph 3
of Section 5 of [RFC7570] also apply to this document.
6. References
6.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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, DOI 10.17487/RFC3471, January 2003,
<http://www.rfc-editor.org/info/rfc3471>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<http://www.rfc-editor.org/info/rfc3473>.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
February 2009, <http://www.rfc-editor.org/info/rfc5420>.
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
"Requirements for Operations, Administration, and
Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
DOI 10.17487/RFC5860, May 2010,
<http://www.rfc-editor.org/info/rfc5860>.
[RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
Extensions for Operations, Administration, and Maintenance
(OAM) Configuration", RFC 7260, DOI 10.17487/RFC7260, June
2014, <http://www.rfc-editor.org/info/rfc7260>.
[RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and B.
Wright, "Label Switched Path (LSP) Attribute in the
Explicit Route Object (ERO)", RFC 7570,
DOI 10.17487/RFC7570, July 2015,
<http://www.rfc-editor.org/info/rfc7570>.
6.2. Informative References
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<http://www.rfc-editor.org/info/rfc5920>.
[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations,
Administration, and Maintenance Framework for MPLS-Based
Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
September 2011, <http://www.rfc-editor.org/info/rfc6371>.
[RFC6435] Boutros, S., Ed., Sivabalan, S., Ed., Aggarwal, R., Ed.,
Vigoureux, M., Ed., and X. Dai, Ed., "MPLS Transport
Profile Lock Instruct and Loopback Functions", RFC 6435,
DOI 10.17487/RFC6435, November 2011,
<http://www.rfc-editor.org/info/rfc6435>.
[RFC7487] Bellagamba, E., Takacs, A., Mirsky, G., Andersson, L.,
Skoldstrom, P., and D. Ward, "Configuration of Proactive
Operations, Administration, and Maintenance (OAM)
Functions for MPLS-Based Transport Networks Using RSVP-
TE", RFC 7487, DOI 10.17487/RFC7487, March 2015,
<http://www.rfc-editor.org/info/rfc7487>.
Acknowledgments
The authors would like to thank Greg Mirsky, Lou Berger, and
Francesco Fondelli for their comments and suggestions.
Authors' Addresses
Jie Dong
Huawei Technologies
Huawei Campus, No.156 Beiqing Rd.
Beijing 100095
China
Email: jie.dong@huawei.com
Mach(Guoyi) Chen
Huawei Technologies
Huawei Campus, No.156 Beiqing Rd.
Beijing 100095
China
Email: mach.chen@huawei.com
Zhenqiang Li
China Mobile
Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave.
Beijing 100053
China
Email: lizhenqiang@chinamobile.com
Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: daniele.ceccarelli@ericsson.com
AI ELI5
On this page
§1Lock Instruct and Loopback
The requirements for Lock Instruct (LI) and Loopback (LB) in the MPLS Transport Profile are in RFC 5860, and their framework is in RFC 6371. A Label Switched Path (LSP) that is locked is prevented from carrying user data traffic. Loopback can only be applied to an LSP that was previously locked.
LI and LB are OAM (Operations, Administration, and Maintenance) functions useful for technologies that use Generalized MPLS (GMPLS) as the control plane, such as time-division multiplexing, wavelength-division multiplexing and packet switching. This RFC extends RSVP-TE so that one approach provisions them all. RFC 7487 covers proactive OAM functions, but not on-demand ones like LI and LB. For MPLS-TP networks, this document complements RFC 6435.
Operators sometimes need to close a path and then test it. This document says how the routers along the path are told to do that.
§2Flags Used for Lock and Loopback
Lock status reuses the A (Administratively down) bit in the Administrative Status (ADMIN_STATUS) object from RFC 3471 and RFC 3473.
Loopback needs a new Loopback flag in the Attribute Flags TLV from RFC 5420. It says that a particular node on the LSP must enter loopback mode, and can also report that node's loopback state. It is bit number 13, carried in Path messages (yes), not in Resv messages (no), and carried in the Record Route Object (RRO) Attributes subobject (yes).
Lock is a switch that already existed. Loopback needed a brand new switch, so the document adds one.
§3.1Locking and Unlocking an LSP
To lock an LSP, the ingress node MUST send a Path message with the A bit set and the Reflect (R) bit in ADMIN_STATUS set. The egress node SHOULD try to take the LSP out of service. On success it MUST send a Resv message with the A bit set. Otherwise it MUST send a PathErr with Error Code OAM Problem and the new Error Value Lock Failure, and following Resv messages MUST have the A bit cleared. While the LSP is locked, later Path and Resv messages MUST keep the A bit set.
Unlocking mirrors this. The ingress sends a Path message with the A bit cleared, and the egress SHOULD try to restore service. On success it MUST send a Resv with the A bit cleared. On failure it MUST send a PathErr with Unlock Failure, and following Resv messages MUST have the A bit set.
The first router says 'close this road'. The last router answers 'done' or 'I could not'. Opening the road again works the same way in reverse.
§3.2Putting a Node into Loopback
A loopback request can go to the egress node or to a particular intermediate node, which is addressed using the mechanism of RFC 7570. The ingress node MUST ensure the LSP is already locked before requesting loopback. It sends a Path message with the Loopback flag set, keeps the A bit set, and MUST make sure the intended entity is explicitly identified by the ERO subobject immediately before the ERO Hop Attributes subobject.
The target node checks that the A bit is set; if not, it MUST ignore the request. It then checks that the ERO subobject type is less than 32, and that type 1 (IPv4 prefix) has prefix length 32 and type 2 (IPv6 prefix) has prefix length 128. If the entity is not explicitly identified, the request is ignored and a Bad EXPLICIT_ROUTE object error SHOULD be generated. Otherwise the node SHOULD try to enter loopback on that entity. If that subobject is a label subobject, loopback applies to the direction given by its U bit.
On success the node sets the Loopback flag when it adds an RRO Hop Attributes subobject, and the A bit stays set. On failure it MUST send a PathErr with OAM Problem and the new value Loopback Failure.
Before turning cars around at one spot, the road must be closed. The chosen spot checks that it really is closed and that it was named clearly, then it does the turnaround.
§3.3Leaving Loopback and Unlocking
To end loopback, the ingress sends a Path message with the Loopback flag cleared, still keeping the A bit set. The target node SHOULD try to leave loopback. On success it MUST clear the flag in the RRO Hop Attributes subobject and push that subobject onto the RRO. Otherwise it MUST send a PathErr with Exit Loopback Failure.
Only after loopback is cleared may the ingress node remove the lock. It MUST NOT request to exit lock mode while the LSP is still in loopback, and the egress node MUST ignore such a request.
You first stop turning cars around, and only then open the road again. Opening it too early is not allowed.
§4IANA Assignments
IANA assigned bit 13, named Loopback, in the Attribute Flags sub-registry. For Path messages the value is yes, for Resv no, and it is allowed in the RRO and ERO.
It also assigned four Error Value sub-codes under the OAM Problem error code: 26 (Lock Failure), 27 (Unlock Failure), 28 (Loopback Failure) and 29 (Exit Loopback Failure). Finally, the allocation rule for Explicit Route Object subobject types 5 to 31 now reads Unassigned, for explicit resource identification.
The official list of numbers was updated so everyone uses the same numbers for these new signals and errors.
- 26Lock Failure — Egress could not lock the LSP.
- 27Unlock Failure — Egress could not unlock the LSP.
- 28Loopback Failure — Node could not enter loopback mode.
- 29Exit Loopback Failure — Node could not leave loopback mode.
§5Security Considerations
The RFC says it introduces no new security issues beyond those in RFC 3209, RFC 3473 and RFC 7570, and points to RFC 5920 for a broader discussion of GMPLS security.
It adds one privacy note: reporting loopback status in the RRO may reveal details about a node that the operator wants to keep confidential. The privacy considerations in paragraph 3 of Section 5 of RFC 7570 also apply.
Telling everyone which spot is being tested might give away secrets, so operators should be careful what they share.