draft-ietf-teas-rsvp-te-li-lb-02.txt   draft-ietf-teas-rsvp-te-li-lb-03.txt 
Network Working Group J. Dong Network Working Group J. Dong
Internet-Draft M. Chen Internet-Draft M. Chen
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: July 13, 2015 Z. Li Expires: July 27, 2015 Z. Li
China Mobile China Mobile
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
January 9, 2015 January 23, 2015
GMPLS RSVP-TE Extensions for Lock Instruct and Loopback GMPLS RSVP-TE Extensions for Lock Instruct and Loopback
draft-ietf-teas-rsvp-te-li-lb-02 draft-ietf-teas-rsvp-te-li-lb-03
Abstract Abstract
This document specifies extensions to Resource Reservation Protocol- This document specifies extensions to Resource Reservation Protocol-
Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and
Loopback (LB) mechanisms for Label Switched Paths (LSPs). These Loopback (LB) mechanisms for Label Switched Paths (LSPs). These
mechanisms are applicable to technologies which use Generalized mechanisms are applicable to technologies which use Generalized
Multi-Protocol Label Switching (GMPLS) as control plane. Multi-Protocol Label Switching (GMPLS) as control plane.
Requirements Language Requirements Language
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 13, 2015. This Internet-Draft will expire on July 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Flag Definitions for LI and LB . . . . . . . . . . . . . . . 3 2. Flag Definitions for LI and LB . . . . . . . . . . . . . . . 3
2.1. Lock Instruct Indication . . . . . . . . . . . . . . . . 3 2.1. Lock Instruct Indication . . . . . . . . . . . . . . . . 3
2.2. Extensions for Loopback . . . . . . . . . . . . . . . . . 3 2.2. Extensions for Loopback . . . . . . . . . . . . . . . . . 3
3. Operational Procedures . . . . . . . . . . . . . . . . . . . 3 3. Operational Procedures . . . . . . . . . . . . . . . . . . . 3
3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4.1. Attribute Flags . . . . . . . . . . . . . . . . . . . . . 5 4.1. Attribute Flags . . . . . . . . . . . . . . . . . . . . . 6
4.2. RSVP Error Value Sub-codes . . . . . . . . . . . . . . . 6 4.2. RSVP Error Value Sub-codes . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The requirements for Lock Instruct (LI) and Loopback (LB) in The requirements for Lock Instruct (LI) and Loopback (LB) in
Multiprotocol Label Switching Transport Profile (MPLS-TP) are Multiprotocol Label Switching Transport Profile (MPLS-TP) are
specified in [RFC5860], and the framework of LI and LB is specified specified in [RFC5860], and the framework of LI and LB is specified
in [RFC6371]. in [RFC6371].
skipping to change at page 4, line 44 skipping to change at page 4, line 44
particular intermediate node. The mechanism defined in particular intermediate node. The mechanism defined in
[I-D.ietf-teas-lsp-attribute-ro] is used for addressing the loopback [I-D.ietf-teas-lsp-attribute-ro] is used for addressing the loopback
request to a particular node on the LSP. The ingress node MUST 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 ensure that the LSP is in lock mode before it requests setting a
particular node on the LSP into loopback mode. particular node on the LSP into loopback mode.
When a ingress node intends to put a particular node on the LSP into When a ingress node intends to put a particular node on the LSP into
loopback mode, it MUST send a Path message with the Loopback loopback mode, it MUST send a Path message with the Loopback
Attribute Flag defined above in the Attribute Flags TLV set. The Attribute Flag defined above in the Attribute Flags TLV set. The
mechanism defined in [I-D.ietf-teas-lsp-attribute-ro] is used to mechanism defined in [I-D.ietf-teas-lsp-attribute-ro] is used to
address the loopback request to the particular node. The address the loopback request to the particular node. The ingress
Administratively down (A) bit in ADMIN_STATUS object MUST be kept set MUST ensure that the desired loopback mode is strictly identified in
to indicate that the LSP is still in lock mode. the ERO. 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 node of the loopback 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 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 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 the bit is not set, the loopback request MUST be ignored. If the bit
is set, the node SHOULD try to put the LSP into loopback mode. If is set, the node MUST check that the desired loopback is strictly
the node puts the LSP into loopback mode successfully, it MUST set identified by verifying that the L bit is set to 0 in both the ERO
the Loopback Attribute Flag if it adds, per [RFC5420], an Attribute Hop Attributes subobject and the prior subobject. The prior
subobject to the RECORD_ROUTE Object (RRO) of a Path or Resv message. subobject MUST also be checked to ensure that it provides strict
The Administratively down (A) bit in ADMIN_STATUS object MUST be kept identification. Currently, the type value MUST be verified to be
set in the message. If the node cannot put the LSP into loopback less than 32, and for type values 1 and 2 the prefix length MUST be
mode, it MUST send a PathErr message with the Error Code "OAM 32 and 128 respectively. If the desired loopback is not strictly
Problem" [RFC7260] and the new Error Value "Loopback Failure". 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. If the node puts the LSP into
loopback mode successfully, it MUST set the Loopback Attribute Flag
if it adds, per [RFC5420], an Attributes subobject to the
RECORD_ROUTE Object (RRO) of a Path or Resv message. The
Administratively down (A) bit in 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 When the ingress node intends to take the particular node out of
loopback mode, it MUST send a Path message with the Loopback loopback mode, it MUST send a Path message with the Loopback
Attribute Flag in the Attribute Flags TLV cleared. The mechanism Attribute Flag in the Attribute Flags TLV cleared. The mechanism
defined in [I-D.ietf-teas-lsp-attribute-ro] is used to indicate that defined in [I-D.ietf-teas-lsp-attribute-ro] is used to indicate that
the particular node SHOULD exit loopback mode for this LSP. The the particular node SHOULD exit loopback mode for this LSP. The
Administratively down (A) bit in ADMIN_STATUS object MUST be kept set Administratively down (A) bit in ADMIN_STATUS object MUST be kept set
to indicate the LSP is still in lock mode. to indicate the LSP is still in lock mode.
On receipt of this Path message, the target node SHOULD try to take 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 the LSP out of loopback mode. If the node takes the LSP out of
loopback mode successfully, it MUST clear the Loopback Attribute Flag loopback mode successfully, it MUST clear the Loopback Attribute Flag
in the RRO Attribute subobject and push this subobject onto the RRO in the RRO Attributes subobject and push this subobject onto the RRO
object in the corresponding Resv message. The Administratively down object in the corresponding Path or Resv message. The
(A) Bit in ADMIN_STATUS Object MUST be kept set in the Resv message. Administratively down (A) Bit in ADMIN_STATUS Object MUST be kept set
Otherwise, the node MUST send a PathErr message with the Error Code in the message. Otherwise, the node MUST send a PathErr message with
"OAM Problem" [RFC7260] and the new Error Value "Exit Loopback the Error Code "OAM Problem" [RFC7260] and the new Error Value "Exit
Failure". Loopback Failure".
After the loopback mode is cleared successfully, the ingress node MAY After the loopback mode is cleared successfully, the ingress node MAY
remove the Lock Instruct using the mechanism defined in section 3.1. 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 The ingress node MUST NOT request to exit lock mode if the LSP is
still in loopback mode. The egress node MUST ignore such request still in loopback mode. The egress node MUST ignore such request
when the LSP is still in loopback mode. when the LSP is still in loopback mode.
4. IANA Considerations 4. IANA Considerations
IANA is requested to administer the assignment of new values defined IANA is requested to administer the assignment of new values defined
in this document and summarized in this section. in this document and summarized in this section.
4.1. Attribute Flags 4.1. Attribute Flags
IANA maintains a registry called "Resource Reservation Protocol- IANA maintains a registry called "Resource Reservation Protocol-
Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called
"Attribute Flags". "Attribute Flags".
IANA is requested to assign a new bit flag as follows: IANA is requested to assign a new bit flag as follows:
Bit | | Attribute | Attribute | | Bit | | Attribute | Attribute | | |
No. | Name | Flags Path | Flags Resv | RRO | Reference No. | Name | Flags Path | Flags Resv | RRO | ERO | Reference
----+--------------+------------+------------+-----+-------------- ----+--------------+------------+------------+-----+-----+-------------
TBA | Loopback | Yes | No | Yes | this document TBA | Loopback | Yes | No | Yes | Yes |this document
4.2. RSVP Error Value Sub-codes 4.2. RSVP Error Value Sub-codes
IANA maintains a registry called "Resource Reservation Protocol IANA maintains a registry called "Resource Reservation Protocol
(RSVP) Parameters" with a sub-registry called "Error Codes and (RSVP) Parameters" with a sub-registry called "Error Codes and
Globally-Defined Error Value Sub-Codes". Globally-Defined Error Value Sub-Codes".
IANA is requested to assign four new Error Value sub-codes for the IANA is requested to assign four new Error Value sub-codes for the
"OAM Problem" Error Code: "OAM Problem" Error Code:
skipping to change at page 7, line 33 skipping to change at page 7, line 42
Operations, Administration, and Maintenance (OAM) in MPLS Operations, Administration, and Maintenance (OAM) in MPLS
Transport Networks", RFC 5860, May 2010. Transport Networks", RFC 5860, May 2010.
[RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE [RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
Extensions for Operations, Administration, and Maintenance Extensions for Operations, Administration, and Maintenance
(OAM) Configuration", RFC 7260, June 2014. (OAM) Configuration", RFC 7260, June 2014.
7.2. Informative References 7.2. Informative References
[I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] [I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext]
Bellagamba, E., Mirsky, G., Andersson, L., Skoldstrom, P., Bellagamba, E., Takacs, A., Mirsky, G., Andersson, L.,
Ward, D., and A. Takacs, "Configuration of Pro-Active Skoldstrom, P., and D. Ward, "Configuration of Pro-Active
Operations, Administration, and Maintenance (OAM) Operations, Administration, and Maintenance (OAM)
Functions for MPLS-based Transport Networks using RSVP- Functions for MPLS-based Transport Networks using RSVP-
TE", draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-14 (work in TE", draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15 (work in
progress), December 2014. progress), January 2015.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks", Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011. RFC 6371, September 2011.
[RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., [RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M.,
and X. Dai, "MPLS Transport Profile Lock Instruct and and X. Dai, "MPLS Transport Profile Lock Instruct and
 End of changes. 12 change blocks. 
31 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/