Internet DRAFT - draft-ietf-ccamp-rsvp-te-li-lb
draft-ietf-ccamp-rsvp-te-li-lb
Network Working Group J. Dong
Internet-Draft M. Chen
Intended status: Standards Track Huawei Technologies
Expires: May 14, 2015 Z. Li
China Mobile
D. Ceccarelli
Ericsson
November 10, 2014
GMPLS RSVP-TE Extensions for Lock Instruct and Loopback
draft-ietf-ccamp-rsvp-te-li-lb-06
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 which use Generalized
Multi-Protocol Label Switching (GMPLS) as control plane.
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 http://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 14, 2015.
Dong, et al. Expires May 14, 2015 [Page 1]
Internet-Draft RSVP-TE Extensions for LI&LB November 2014
Copyright Notice
Copyright (c) 2014 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
2. Flag Definitions for LI and LB . . . . . . . . . . . . . . . 3
2.1. Lock Instruct Indication . . . . . . . . . . . . . . . . 3
2.2. Extensions for Loopback . . . . . . . . . . . . . . . . . 3
3. Operational Procedures . . . . . . . . . . . . . . . . . . . 4
3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4.1. Attribute Flags . . . . . . . . . . . . . . . . . . . . . 6
4.2. RSVP Error Value Sub-codes . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The requirements for Lock Instruct (LI) and Loopback (LB) in
Multiprotocol Label Switching Transport Profile (MPLS-TP) are
specified in [RFC5860], and the framework of LI and LB is specified
in [RFC6371].
In general the LI and LB are useful Operations, Administration and
Maintenance (OAM) functions for technologies which use Generalized
Multi-Protocol Label Switching (GMPLS) as 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.
Dong, et al. Expires May 14, 2015 [Page 2]
Internet-Draft RSVP-TE Extensions for LI&LB November 2014
[I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] specifies the RSVP-TE
extensions for the configuration of pro-active 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 Label Switched Paths (LSPs). The mechanisms are
applicable to technologies which use GMPLS as control plane. For
MPLS-TP network, the mechanisms defined in this document are
complementary to [RFC6435].
2. Flag Definitions for LI and LB
2.1. Lock Instruct Indication
In order to indicate the lock/unlock of the LSP, the A
(Administratively down) bit in ADMIN_STATUS object [RFC3471]
[RFC3473] is used. The format of ADMIN_STATUS Object is as below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(196)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |M|O|H|L|I|C|T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Admin_Status Object
Reflect (R): 1 bit - see [RFC3471]
OAM Flows Enabled (M): 1 bit - see [RFC7260]
OAM Alarms Enabled (O): 1 bit - see [RFC7260]
Handover (H): 1 bit - see [RFC5852]
Lockout (L): 1 bit - see [RFC4872]
Inhibit Alarm Indication (I): 1 bit - see [RFC4783]
Call Control (C): 1 bit - see [RFC4974]
Testing (T): 1 bit - see [RFC3471]
Administratively down (A): 1 bit - see [RFC3471], reused for Lock
Deletion in progress (D): 1 bit - see [RFC3471]
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:
Dong, et al. Expires May 14, 2015 [Page 3]
Internet-Draft RSVP-TE Extensions for LI&LB November 2014
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: TBA
- Attribute flag carried in Path message: Yes
- Attribute flag carried in Resv message: No
- Attribute flag carried in RRO Attributes subobject: Yes
3. Operational Procedures
3.1. Lock Instruct
When an ingress Label Switching Router (LSR) intends to put an LSP
into lock mode, it MUST send a Path message with the Administratively
down (A) bit defined above and the Reflect (R) bit in ADMIN_STATUS
Object set.
On receipt of this Path message, the egress LSR SHOULD try to take
the LSP out of service. If the egress LSR locks the LSP
successfully, it MUST send a Resv message with the A bit in
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 SHOULD keep the A bit in ADMIN_STATUS Object set.
When the ingress LSR intends to take the LSP out of the lock mode, it
MUST send a Path message with the A bit in ADMIN_STATUS Object
cleared.
On receipt of this Path message, the egress LSR SHOULD try to bring
the LSP back to service. If the egress LSR unlocks the LSP
successfully, it MUST send a Resv message with the A bit in
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 SHOULD keep the A bit in ADMIN_STATUS Object cleared.
Dong, et al. Expires May 14, 2015 [Page 4]
Internet-Draft RSVP-TE Extensions for LI&LB November 2014
3.2. Loopback
The loopback request can be sent either to the egress LSR or to a
particular intermediate node. The mechanism defined in
[I-D.ietf-ccamp-lsp-attribute-ro] is used for addressing the loopback
request to a particular node on the LSP. The ingress LSR MUST ensure
that the LSP is in lock mode before it requests setting a particular
node on the LSP into loopback mode.
When a ingress LSR intends to put a particular node on the LSP into
loopback mode, it MUST send a Path message with the Loopback bit
defined above in the Attribute Flags TLV set. The mechanism defined
in [I-D.ietf-ccamp-lsp-attribute-ro] is used to address the loopback
request to the particular LSR. The Administratively down (A) bit in
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 LSR of the loopback
request SHOULD try to put the LSP into loopback mode. If the node
puts the LSP into loopback mode successfully, it MUST set the
Loopback (B) bit in the Record Route Object (RRO) Attribute subobject
[RFC5420] and push this subobject onto the RRO object in the
corresponding Resv message. The Administratively down (A) bit in
ADMIN_STATUS object MUST be kept set in the Resv 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 LSR intends to take the particular node out of
loopback mode, it MUST send a Path message with the Loopback (B) bit
in the Attribute Flags TLV cleared. The mechanism defined in
[I-D.ietf-ccamp-lsp-attribute-ro] is used to indicate that the
particular LSR SHOULD exit loopback mode for this LSP. The
Administratively down (A) bit in ADMIN_STATUS object MUST be kept set
to indicate the LSP is still in lock mode.
On receipt of this Path message, the target LSR 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 (B) Bit in the
RRO Attribute subobject and push this subobject onto the RRO object
in the corresponding Resv message. The Administratively down (A) Bit
in ADMIN_STATUS Object MUST be kept set in the Resv 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 LSR MAY
remove the Lock Instruct using the mechanism defined in section 3.1.
Dong, et al. Expires May 14, 2015 [Page 5]
Internet-Draft RSVP-TE Extensions for LI&LB November 2014
4. IANA Considerations
IANA is requested to administer the assignment of 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 is requested to assign a new bit flag as follows:
Bit | | Attribute | Attribute | |
No. | Name | Flags Path | Flags Resv | RRO | Reference
----+--------------+------------+------------+-----+--------------
TBA | Loopback | Yes | No | 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 is requested to assign four new Error Value sub-codes for the
"OAM Problem" Error Code:
Value | Description | Reference
-----------+-----------------------------+--------------
TBA | Lock Failure | this document
TBA | Unlock Failure | this document
TBA | Loopback Failure | this document
TBA | Exit Loopback Failure | this document
5. Security Considerations
This document does not introduce any new security issues above those
identified in [RFC3209] and [RFC3473]. For a more comprehensive
discussion of GMPLS security and attack mitigation techniques, please
see the Security Framework for MPLS and GMPLS Networks [RFC5920].
6. Acknowledgements
The authors would like to thank Greg Mirsky, Lou Berger and Francesco
Fondelli for their comments and suggestions.
Dong, et al. Expires May 14, 2015 [Page 6]
Internet-Draft RSVP-TE Extensions for LI&LB November 2014
7. References
7.1. Normative References
[I-D.ietf-ccamp-lsp-attribute-ro]
Margaria, C., Martinelli, G., Balls, S., and B. Wright,
"LSP Attribute in ERO", draft-ietf-ccamp-lsp-attribute-
ro-05 (work in progress), October 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
Operations, Administration, and Maintenance (OAM) in MPLS
Transport Networks", RFC 5860, May 2010.
[RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
Extensions for Operations, Administration, and Maintenance
(OAM) Configuration", RFC 7260, June 2014.
7.2. Informative References
[I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext]
Bellagamba, E., Andersson, L., Skoldstrom, P., Ward, D.,
and A. Takacs, "Configuration of Pro-Active Operations,
Administration, and Maintenance (OAM) Functions for MPLS-
based Transport Networks using RSVP-TE", draft-ietf-ccamp-
rsvp-te-mpls-tp-oam-ext-12 (work in progress), June 2013.
[RFC4783] Berger, L., "GMPLS - Communication of Alarm Information",
RFC 4783, December 2006.
Dong, et al. Expires May 14, 2015 [Page 7]
Internet-Draft RSVP-TE Extensions for LI&LB November 2014
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872, May
2007.
[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS)
RSVP-TE Signaling Extensions in Support of Calls", RFC
4974, August 2007.
[RFC5852] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S.
Bardalai, "RSVP-TE Signaling Extension for LSP Handover
from the Management Plane to the Control Plane in a GMPLS-
Enabled Transport Network", RFC 5852, April 2010.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011.
[RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M.,
and X. Dai, "MPLS Transport Profile Lock Instruct and
Loopback Functions", RFC 6435, November 2011.
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
Dong, et al. Expires May 14, 2015 [Page 8]
Internet-Draft RSVP-TE Extensions for LI&LB November 2014
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
Dong, et al. Expires May 14, 2015 [Page 9]
