Internet DRAFT - draft-dong-ccamp-rsvp-te-mpls-tp-li-lb
draft-dong-ccamp-rsvp-te-mpls-tp-li-lb
Network Working Group J. Dong
Internet-Draft M. Chen
Intended status: Standards Track Huawei Technologies
Expires: June 7, 2013 Z. Li
China Mobile
December 4, 2012
GMPLS RSVP-TE Extensions for Lock Instruct and Loopback
draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05
Abstract
This document specifies extensions to RSVP-TE to support lock
instruct and loopback mechanism for LSPs. The mechanisms are
applicable to technologies which use 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 June 7, 2013.
Copyright Notice
Copyright (c) 2012 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
Dong, et al. Expires June 7, 2013 [Page 1]
Internet-Draft RSVP-TE Extensions for LI&LB December 2012
(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 June 7, 2013 [Page 2]
Internet-Draft RSVP-TE Extensions for LI&LB December 2012
1. Introduction
The requirements for Lock Instruct (LI) and Loopback (LB) in 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 OAM functions for technologies
which use 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.
This document specifies extensions to RSVP-TE to support lock
instruct and loopback mechanism for 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. Extensions to RSVP-TE
The A (Administratively down) bit in ADMIN_STATUS object [RFC3471]
[RFC3473] is used to indicate the lock/unlock of the LSP. 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 |H|L|I|C|T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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], reused for Lock
Deletion in progress (D): 1 bit - see [RFC3471]
A new bit is defined in Attribute Flags TLV [RFC5420] to indicate the
loopback mode. The bit number is TBA.
Dong, et al. Expires June 7, 2013 [Page 3]
Internet-Draft RSVP-TE Extensions for LI&LB December 2012
Bit Number Name and Usage
TBA Loopback mode desired.
This flag indicates a particular node on the LSP is required
to enter loopback mode.
This MAY also be used for specifying the loopback state
of the node.
3. Operations
3.1. Lock Instruct
When an ingress LSR wants to put an LSP into lock mode, it MUST send
a Path message with the Administratively down (A) bit and the Reflect
(R) bit in ADMIN_STATUS Object set. The intermediate nodes SHOULD
forward the message with the A bit unchanged to the downstream .
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 SHOULD send a Resv message with the A 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 messages SHOULD be sent with the A
bit cleared. With this procedure, the intermediate nodes would also
be aware of whether the LSP is in Lock mode or not.
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 wants to take the LSP out of the lock mode, it
MUST send a Path message with the A bit in ADMIN_STATUS Object
cleared. The intermediate nodes SHOULD forward this message with the
A bit unchanged to the downstream.
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 SHOULD send a Resv message with the A bit in
ADMIN_STATUS Object cleared. Otherwise, it SHOULD send a PathErr
message with the Error Code "OAM Problem" and the new Error Value
"Unlock Failure", and the following Resv messages SHOULD 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 June 7, 2013 [Page 4]
Internet-Draft RSVP-TE Extensions for LI&LB December 2012
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.margaria-ccamp-lsp-attribute-ero] is used for addressing the
loopback request to a particular node on the LSP. The loopback
request is acceptable only when the LSP is in lock mode.
When a ingress LSR wants to put a particular LSR on the LSP into
loopback mode, it MUST send a Path message with the Loopback bit in
the Attribute Flags TLV set. The mechanism defined in
[I-D.margaria-ccamp-lsp-attribute-ero] is used to address the
loopback request to the particular LSR. The Administratively down
(A) bit in ADMIN_STATUS object SHOULD be set to keep the LSP 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 SHOULD set the
Loopback (B) bit in the 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 SHOULD also
be set in the Resv message. If the node cannot put the LSP into
loopback mode, it SHOULD send a PathErr message with the Error Code
"OAM Problem" and the new Error Value "Loopback Failure".
When the ingress LSR wants to take the LSP 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.margaria-ccamp-lsp-attribute-ero] is used to indicate that the
particular LSR SHOULD exit loopback mode for this LSP. The
Administratively down (A) bit in ADMIN_STATUS object SHOULD be set.
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 SHOULD 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 SHOULD be set. Otherwise, the node
SHOULD send a PathErr message with the Error Code "OAM Problem" and
the new Error Value "Exit Loopback Failure".
4. IANA Considerations
One bit number Loopback needs to be assigned in the Attribute Flags
registry.
Dong, et al. Expires June 7, 2013 [Page 5]
Internet-Draft RSVP-TE Extensions for LI&LB December 2012
Four new Error Values need to be allocated for Error Code "OAM
Problem": "Lock Failure", "Unlock Failure", "Loopback Failure", "Exit
Loopback Failure".
5. Security Considerations
This document does not introduce any new security issues above those
identified in [RFC3209] and [RFC3473].
6. Acknowledgements
The authors would like to thank Greg Mirsky, Lou Berger and Francesco
Fondelli for their comments and suggestions.
7. References
7.1. Normative References
[I-D.ietf-ccamp-oam-configuration-fwk]
Takacs, A., Fedyk, D., and H. Jia, "GMPLS RSVP-TE
extensions for OAM Configuration",
draft-ietf-ccamp-oam-configuration-fwk-08 (work in
progress), July 2012.
[I-D.margaria-ccamp-lsp-attribute-ero]
Margaria, C., Schroetter, D., Martinelli, G., Balls, S.,
and B. Wright, "LSP Attribute in ERO",
draft-margaria-ccamp-lsp-attribute-ero-02 (work in
progress), October 2012.
[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.
Dong, et al. Expires June 7, 2013 [Page 6]
Internet-Draft RSVP-TE Extensions for LI&LB December 2012
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[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.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011.
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-10 (work in
progress), October 2012.
[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 Building, No.156 Beiqing Rd.
Beijing 100095
China
Email: jie.dong@huawei.com
Dong, et al. Expires June 7, 2013 [Page 7]
Internet-Draft RSVP-TE Extensions for LI&LB December 2012
Mach Chen
Huawei Technologies
Huawei Building, 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
Dong, et al. Expires June 7, 2013 [Page 8]
