Network Working Group J. Dong
Internet-Draft M. Chen
Intended status: Standards Track Huawei Technologies
Expires: May 3, 2012 Z. Li
China Mobile
October 31, 2011
RSVP-TE Extensions for Lock Instruct and Loopback in MPLS Transport
Profile
draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-01
Abstract
This document specifies extensions to RSVP-TE to support lock
instruct and loopback mechanism for MPLS-TP LSPs. The mechanisms are
intended to be applicable to other aspects of MPLS as well.
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 3, 2012.
Copyright Notice
Copyright (c) 2011 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
Dong, et al. Expires May 3, 2012 [Page 1]
Internet-Draft RSVP-TE Extensions for LI&LB October 2011
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Extensions to RSVP-TE . . . . . . . . . . . . . . . . . . . . . 3
3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Dong, et al. Expires May 3, 2012 [Page 2]
Internet-Draft RSVP-TE Extensions for LI&LB October 2011
1. Introduction
The requirements of Lock Instruct (LI) and Loopback (LB) are
specified in [RFC5860]. [I-D.ietf-mpls-tp-li-lb] defines in-band
Lock Instruct (LI) and Loopback (LB) functions, it leverages the
Generic Associated Channel (GACH) and Generic Associated Channel
Label (GAL) [RFC5586] and the management plane to perform LI function
and use management plane to perform the LB function. In-band LI and
LB is suitable for the scenarios where control plane is not used.
When a control plane is used for establishing MPLS-TP LSPs, it's
natural to use and extend the control plane protocol to implement LI
and LB functions. Since LI and LB would modify the forwarding plane
of an LSP, without the involvement of control plane this may result
in inconsistency of the LSP information between control plane and
data plane. Besides, with control plane mechanisms, it does not need
to rely on the TTL expiration to make the LI/LB commands to reach
particular MIP or MEP.
This document specifies extensions to RSVP-TE to implement LI and LB
for MPLS-TP LSPs when MPLS-TP control plane is used. The mechanisms
defined in this document are complementary to
[I-D.ietf-mpls-tp-li-lb].
2. Extensions to RSVP-TE
In this document, Path and Resv message are used to implement LI
function, and Notify message is used for LB functions. Two new flags
(Lock bit and Loopback bit) are defined in ADMIN_STATUS Object
[RFC3471] [RFC3473] that can be carried in Path/Resv and Notify
message.
Format of extended 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 |K|B|H|L|I|C|T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lock (K): When this bit is set in Path message, it indicates that
local actions related to the "Lock" mode should be taken. When this
bit is set in Resv or Notify message, it indicates that the LSP is
put in "Lock" mode.
Dong, et al. Expires May 3, 2012 [Page 3]
Internet-Draft RSVP-TE Extensions for LI&LB October 2011
Loopback (B): When this bit is set in Notify message sent from the
ingress node, it indicates that the target node of this message
SHOULD perform loopback function for this LSP. When this bit is set
in Notify message sent to the ingress node, it indicates the node
originating this message is in "Loopback" mode.
Reflect (R): 1 bit - see [RFC3471]
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]
Deletion in progress (D): 1 bit - see [RFC3471]
3. Operations
3.1. Lock Instruct
When a MEP wants to put an LSP in lock mode, it MUST send a Path
message with the Lock (K) bit and the Reflect (R) bit in ADMIN_STATUS
Object set. The intermediate nodes do not need to take action on
this message and SHOULD forward it unchanged to the downstream.
On receipt of this Path message, the receiving MEP node SHOULD try to
take the LSP out of service. If the receiving MEP locks the LSP
successfully, it SHOULD send a Resv message with the Lock (K) bit in
ADMIN_STATUS Object set. Otherwise, it SHOULD send a PathErr message
with the Error Code "OAM Problem" and the new Error Value "Lock
Failure", and the following Resv message SHOULD be sent with the Lock
(K) bit cleared. Though the intermediate nodes do not need to take
actions during this procedure, they would be aware of whether the LSP
is put in Lock mode or not.
When an LSP is put in lock mode, the subsequent Path and Resv
messages SHOULD keep the Lock (K) bit in ADMIN_STATUS Object set.
When a MEP wants to take the LSP out of the lock mode, it MUST send a
Path message with the Lock (K) bit cleared. The intermediate nodes
do not need to take action on this message and SHOULD forward it
unchanged to the downstream.
On receipt of this Path message, the receiving MEP node SHOULD try to
bring the LSP back to service. If the receiving MEP unlocks the LSP
successfully, it SHOULD send a Resv message with the Lock (K) bit in
ADMIN_STATUS Object cleared. Otherwise, it SHOULD send a PathErr
message with the Error Code "OAM Problem" and the new Error Value
Dong, et al. Expires May 3, 2012 [Page 4]
Internet-Draft RSVP-TE Extensions for LI&LB October 2011
"Unlock Failure", and the following Resv message SHOULD be sent with
the Lock (K) bit set.
3.2. Loopback
Notify message is used to support signaling of Loopback request.
When a MEP wants to put an LSP in loopback mode, it MUST send a
Notify message with the Reflect (R) bit, the Loopback (B) Bit and the
Lock (K) bit in ADMIN_STATUS Object set. The destination address of
this Notify message SHOULD be set to the MIP or MEP which is required
to loopback the traffic. The ERROR_SPEC object is not relevant in
loopback request and MUST carry the Error Code zero ("Confirmation")
to indicate that there is no error.
On receipt of this Notify message, the receiver node SHOULD try to
put the LSP in loopback mode. If the receiver node puts the LSP into
loopback mode successfully, it SHOULD send a Notify message back to
the MEP node, with both the Loopback (B) Bit and the Lock (K) bit in
ADMIN_STATUS Object set, and the ERROR_SPEC object MUST carry the
Error Code zero. Otherwise, it SHOULD send a Notify message with the
Error Code "OAM Problem" and the new Error Value "Loopback Failure".
When a MEP wants to take the LSP out of the loopback mode, it MUST
send a Notify message with the Lock (K) bit set and the Loopback (B)
Bit cleared. The destination address of this Notify message SHOULD
be set to the MIP or MEP which is performing the loopback action for
this LSP.
On receipt of this Notify message, the receiving node SHOULD try to
put the LSP back to normal operation. If the receiving node put the
LSP into normal operation successfully, it SHOULD send a Notify
message back to the MEP node, with the Lock (K) Bit set and the
Loopback (B) Bit cleared , and the ERROR_SPEC object MUST carry the
Error Code zero. Otherwise, it SHOULD send a Notify message with the
Error Code "OAM Problem" and the new Error Value "Exit Loopback
Failure".
4. IANA Considerations
Two bits ("Lock" (K) and "Loopback" (B)) need to be allocated in the
ADMIN_STATUS Object.
Four new Error Values need to be allocated for Error Code "OAM
Problem": "Lock Failure", "Unlock Failure", "Loopback Failure", "Exit
Loopback Failure".
Dong, et al. Expires May 3, 2012 [Page 5]
Internet-Draft RSVP-TE Extensions for LI&LB October 2011
5. Security Considerations
This document does not introduce any new security issues above those
identified in [RFC3209] and [RFC3473].
6. Acknowledgements
TBD
7. References
7.1. Normative References
[I-D.ietf-ccamp-oam-configuration-fwk]
Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
extensions for OAM Configuration",
draft-ietf-ccamp-oam-configuration-fwk-06 (work in
progress), July 2011.
[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.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
Operations, Administration, and Maintenance (OAM) in MPLS
Dong, et al. Expires May 3, 2012 [Page 6]
Internet-Draft RSVP-TE Extensions for LI&LB October 2011
Transport Networks", RFC 5860, May 2010.
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-06 (work in
progress), July 2011.
[I-D.ietf-mpls-tp-li-lb]
Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M.,
and X. Dai, "MPLS Transport Profile lock Instruct and
Loopback Functions", draft-ietf-mpls-tp-li-lb-08 (work in
progress), October 2011.
[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS)
RSVP-TE Signaling Extensions in Support of Calls",
RFC 4974, August 2007.
Authors' Addresses
Jie Dong
Huawei Technologies
Huawei Building, No.156 Beiqing Rd
Beijing 100095
China
Email: jie.dong@huawei.com
Mach Chen
Huawei Technologies
Huawei Building, No.156 Beiqing Rd
Beijing 100095
China
Email: mach.chen@huawei.com
Dong, et al. Expires May 3, 2012 [Page 7]
Internet-Draft RSVP-TE Extensions for LI&LB October 2011
Zhenqiang Li
China Mobile
Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave.
Beijing 100053
China
Email: lizhenqiang@chinamobile.com
Dong, et al. Expires May 3, 2012 [Page 8]