draft-ietf-teas-rsvp-te-li-lb-05.txt   rfc7571.txt 
Network Working Group J. Dong Internet Engineering Task Force (IETF) J. Dong
Internet-Draft M. Chen Request for Comments: 7571 M. Chen
Intended status: Standards Track Huawei Technologies Category: Standards Track Huawei Technologies
Expires: September 5, 2015 Z. Li ISSN: 2070-1721 Z. Li
China Mobile China Mobile
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
March 4, 2015 July 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-05
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 that use Generalized MPLS
Multi-Protocol Label Switching (GMPLS) for the control plane. (GMPLS) for the 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on September 5, 2015. 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 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . 4 3. Operational Procedures . . . . . . . . . . . . . . . . . . . 3
3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4.1. Attribute Flags . . . . . . . . . . . . . . . . . . . . . 6 4.1. Attribute Flags . . . . . . . . . . . . . . . . . . . . . 6
4.2. RSVP Error Value Sub-codes . . . . . . . . . . . . . . . 6 4.2. RSVP Error Value Sub-Codes . . . . . . . . . . . . . . . 6
4.3. Allocation Rule for ERO Subobjects . . . . . . . . . . . 6 4.3. Allocation Rule for ERO Subobjects . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The requirements for Lock Instruct (LI) and Loopback (LB) in the The requirements for Lock Instruct (LI) and Loopback (LB) in the
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]. An LSP that is locked, using LI, is prevented from in [RFC6371]. A Label Switched Path (LSP) that is locked, using LI,
carrying user data traffic. The LB function can only be applied to is prevented from carrying user data traffic. The LB function can
an LSP that has been previously locked. only be applied to an LSP that has been previously locked.
In general the LI and LB are useful Operations, Administration and In general, the LI and LB are useful Operations, Administration, and
Maintenance (OAM) functions for technologies which use Generalized Maintenance (OAM) functions for technologies that use Generalized
Multi-Protocol Label Switching (GMPLS) for the control plane, e.g., MPLS (GMPLS) for the control plane, e.g., time-division multiplexing,
time-division multiplexing, wavelength-division multiplexing and wavelength-division multiplexing, and packet switching. It is
packet switching. It is natural to use and extend the GMPLS control natural to use and extend the GMPLS control-plane protocol to provide
plane protocol to provide a unified approach for LI and LB a unified approach for LI and LB provisioning in all these
provisioning in all these technologies. technologies.
[I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] specifies the RSVP-TE [RFC7487] specifies the RSVP-TE extensions for the configuration of
extensions for the configuration of pro-active MPLS-TP OAM functions, proactive MPLS-TP OAM functions, such as Continuity Check (CC),
such as Continuity Check (CC), Connectivity Verification (CV), Delay Connectivity Verification (CV), Delay Measurement (DM), and Loss
Measurement (DM) and Loss Measurement (LM). The provisioning of on- Measurement (LM). The provisioning of on-demand OAM functions such
demand OAM functions such as LI and LB are not covered in that as LI and LB are not covered in that document.
document.
This document specifies extensions to Resource Reservation Protocol- This document specifies extensions to Resource Reservation Protocol-
Traffic Engineering (RSVP-TE) to support lock instruct and loopback Traffic Engineering (RSVP-TE) to support lock instruct and loopback
mechanisms for Label Switched Paths (LSPs). The mechanisms are mechanisms for LSPs. The mechanisms are applicable to technologies
applicable to technologies which use GMPLS for the control plane. that use GMPLS for the control plane. For a network supporting MPLS-
For a network supporting MPLS-TP, the mechanisms defined in this TP, the mechanisms defined in this document are complementary to
document are complementary to [RFC6435]. [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. Flag Definitions for LI and LB
2.1. Lock Instruct Indication 2.1. Lock Instruct Indication
In order to indicate the lock/unlock status of the LSP, the A In order to indicate the lock/unlock status of the LSP, the A
(Administratively down) bit in the Administrative Status (Administratively down) bit in the Administrative Status
(ADMIN_STATUS) object [RFC3471] [RFC3473] is used. (ADMIN_STATUS) Object [RFC3471] [RFC3473] is used.
2.2. Extensions for Loopback 2.2. Extensions for Loopback
In order to indicate the loopback mode of LSP, a new bit flag is In order to indicate the loopback mode of LSP, a new bit flag is
defined in the Attribute Flags TLV [RFC5420]. defined in the Attribute Flags TLV [RFC5420].
Loopback flag: Loopback flag:
This flag indicates a particular node on the LSP is required to This flag indicates a particular node on the LSP is required to
enter loopback mode. This can also be used for specifying the enter loopback mode. This can also be used for specifying the
loopback state of the node. loopback state of the node.
- Bit number: TBA-1 - Bit number: 13
- Attribute flag carried in Path message: Yes - Attribute flag carried in Path message: Yes
- Attribute flag carried in Resv message: No - Attribute flag carried in Resv message: No
- Attribute flag carried in RRO Attributes subobject: Yes - Attribute flag carried in the Record Route Object (RRO)
Attributes subobject: Yes
3. Operational Procedures 3. Operational Procedures
3.1. Lock Instruct 3.1. Lock Instruct
When an ingress node intends to put an LSP into lock mode, it MUST 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 send a Path message with the Administratively down (A) bit used as
specified above and the Reflect (R) bit in the ADMIN_STATUS Object specified above and the Reflect (R) bit in the ADMIN_STATUS Object
set. set.
On receipt of this Path message, the egress node SHOULD try to take 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 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 successfully, it MUST send a Resv message with the A bit in the
ADMIN_STATUS object set. Otherwise, it MUST send a PathErr message ADMIN_STATUS Object set. Otherwise, it MUST send a PathErr message
with the Error Code "OAM Problem" [RFC7260] and the new Error Value with the Error Code "OAM Problem" [RFC7260] and the new Error Value
"Lock Failure", and the following Resv messages MUST be sent with the "Lock Failure", and the following Resv messages MUST be sent with the
A bit cleared. A bit cleared.
When an LSP is put in lock mode, the subsequent Path and Resv 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. 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, 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 it MUST send a Path message with the A bit in the ADMIN_STATUS Object
cleared. cleared.
skipping to change at page 4, line 43 skipping to change at page 4, line 34
message with the Error Code "OAM Problem" [RFC7260] and the new Error message with the Error Code "OAM Problem" [RFC7260] and the new Error
Value "Unlock Failure", and the following Resv messages MUST be sent Value "Unlock Failure", and the following Resv messages MUST be sent
with the A bit set. with the A bit set.
When an LSP is taken out of lock mode, the subsequent Path and Resv 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. messages MUST keep the A bit in the ADMIN_STATUS Object cleared.
3.2. Loopback 3.2. Loopback
The loopback request can be sent either to the egress node or to a The loopback request can be sent either to the egress node or to a
particular intermediate node. The mechanism defined in particular intermediate node. The mechanism defined in [RFC7570] is
[I-D.ietf-teas-lsp-attribute-ro] is used for addressing the loopback used for addressing the loopback request to a particular node on the
request to a particular node on the LSP. The ingress node MUST LSP. The ingress node MUST ensure that the LSP is in lock mode
ensure that the LSP is in lock mode before it requests setting a before it requests setting a particular node on the LSP into loopback
particular node on the LSP into loopback mode. mode.
When a ingress node intends to put a particular node on the LSP into 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 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 [RFC7570] is used to address the loopback
address the loopback request to the particular node. The ingress request to the particular node. The ingress node MUST ensure that
node MUST ensure that the entity (node or interface), at which the entity at which loopback is intended to occur is explicitly
loopback is intended to occur, is marked as a strict hop in the identified by the immediately preceding subobject of the Explicit
Explicit Route Object (ERO) subobject. The Administratively down (A) Route Object (ERO) Hop Attributes subobject. The Administratively
bit in the ADMIN_STATUS object MUST be kept set to indicate that the down (A) bit in the ADMIN_STATUS Object MUST be kept set to indicate
LSP is still in lock mode. 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 MUST check that the desired loopback entity is is set, the node MUST check that the desired loopback entity is
explicitly identified by the ERO subobject prior to the ERO Hop explicitly identified by the ERO subobject prior to the ERO Hop
Attributes subobject. Currently, the type value MUST be verified to Attributes subobject. Currently, the type value MUST be verified to
be less than 32 (i.e., able to identify a specific entity where a 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 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 prefix) and 2 (IPv6 prefix), the prefix length MUST be 32 and 128,
respectively. If the desired loopback entity is not explicitly respectively. If the desired loopback entity is not explicitly
identified, the request MUST be ignored and a "Bad EXPLICIT_ROUTE identified, the request MUST be ignored and a "Bad EXPLICIT_ROUTE
object" error SHOULD be generated. Otherwise, the node SHOULD try to object" error SHOULD be generated. Otherwise, the node SHOULD try to
put the LSP into loopback mode. If the node puts the LSP into put the LSP into loopback mode. The loopback SHOULD be enabled on
loopback mode successfully, it MUST set the Loopback Attribute Flag the entity identified by the ERO subobject immediately prior to the
if it adds, per [I-D.ietf-teas-lsp-attribute-ro], an RRO Hop ERO Hop Attributes subobject. If the immediately preceding subobject
Attributes subobject to the RECORD_ROUTE Object (RRO) of a Path or is a label subobject [RFC3473], the loopback SHOULD be enabled for
Resv message. The Administratively down (A) bit in the ADMIN_STATUS the direction indicated by the U bit of the label subobject.
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 If the node puts the LSP into loopback mode successfully, it MUST set
Code "OAM Problem" [RFC7260] and the new Error Value "Loopback the Loopback Attribute Flag if it adds, per [RFC7570], an RRO Hop
Failure". 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 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 [RFC7570] is used to indicate that the particular node
the particular node SHOULD exit loopback mode for this LSP. The SHOULD exit loopback mode for this LSP. The Administratively down
Administratively down (A) bit in the ADMIN_STATUS object MUST be kept (A) bit in the ADMIN_STATUS Object MUST be kept set to indicate the
set to indicate the LSP is still in lock mode. 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 Hop Attributes subobject and push this subobject onto the in the RRO Hop Attributes subobject and push this subobject onto the
RRO object in the corresponding Path or Resv message. The RRO object in the corresponding Path or Resv message. The
Administratively down (A) Bit in the ADMIN_STATUS Object MUST be kept Administratively down (A) bit in the ADMIN_STATUS Object MUST be kept
set in the message. Otherwise, the node MUST send a PathErr message set in the message. Otherwise, the node MUST send a PathErr message
with the Error Code "OAM Problem" [RFC7260] and the new Error Value with the Error Code "OAM Problem" [RFC7260] and the new Error Value
"Exit Loopback Failure". "Exit 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 a 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 has assigned new values defined in this document and summarized
in this document and summarized in this section. 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 has assigned a new bit flag as follows:
Bit | | Attribute | Attribute | | | Bit | | Attribute | Attribute | | |
No. | Name | Flags Path | Flags Resv | RRO | ERO | Reference No. | Name | Flags Path | Flags Resv | RRO | ERO | Reference
-----+-----------+------------+------------+-----+-----+------------- -----+-----------+------------+------------+-----+-----+-------------
TBA-1| Loopback | Yes | No | Yes | Yes |this document 13 | 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 has assigned four new Error Value sub-codes for the "OAM
"OAM Problem" Error Code: Problem" Error Code:
Value | Description | Reference Value | Description | Reference
-----------+-----------------------------+-------------- -----------+-----------------------------+--------------
TBA-2 | Lock Failure | this document 26 | Lock Failure | this document
TBA-3 | Unlock Failure | this document 27 | Unlock Failure | this document
TBA-4 | Loopback Failure | this document 28 | Loopback Failure | this document
TBA-5 | Exit Loopback Failure | this document 29 | Exit Loopback Failure | this document
4.3. Allocation Rule for ERO Subobjects 4.3. Allocation Rule for ERO Subobjects
IANA maintains a registry called "Resource Reservation Protocol IANA maintains a registry called "Resource Reservation Protocol
(RSVP) Parameters" with a sub-registry called "Class Names, Class (RSVP) Parameters" with a sub-registry called "Class Names, Class
Numbers, and Class Types". Numbers, and Class Types".
For Explicit Route Object , the allocation rule for subobject types For Explicit Route Object, the allocation rule for subobject types in
in the range 5 - 31 (0x05 - 0x1F) needs to be updated as: the range 5-31 (0x05 - 0x1F) has been updated as:
5-31 Unassigned (For explicit resource identification) 5-31 Unassigned (For explicit resource identification)
5. Security Considerations 5. Security Considerations
This document does not introduce any new security issues above those This document does not introduce any new security issues beyond those
identified in [RFC3209] [RFC3473] and identified in [RFC3209], [RFC3473], and [RFC7570]. For a more
[I-D.ietf-teas-lsp-attribute-ro]. For a more comprehensive comprehensive discussion of GMPLS security and attack mitigation
discussion of GMPLS security and attack mitigation techniques, please techniques, please see "Security Framework for MPLS and GMPLS
see the Security Framework for MPLS and GMPLS Networks [RFC5920]. Networks" [RFC5920].
In addition, the reporting of the loopback status using the RRO may In addition, the reporting of the loopback status using the RRO may
reveal details about the node that the operator wishes to remain reveal details about the node that the operator wishes to remain
confidential. The privacy considerations as described in section 5, confidential. The privacy considerations as described in paragraph 3
paragraph 3 of [I-D.ietf-teas-lsp-attribute-ro] also apply to this of Section 5 of [RFC7570] also apply to this document.
document.
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 6. References
[I-D.ietf-teas-lsp-attribute-ro] 6.1. Normative References
Margaria, C., Martinelli, G., Balls, S., and B. Wright,
"LSP Attribute in ERO", draft-ietf-teas-lsp-attribute-
ro-03 (work in progress), March 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
(GMPLS) Signaling Functional Description", RFC 3471, Switching (GMPLS) Signaling Functional Description", RFC
January 2003. 3471, DOI 10.17487/RFC3471, January 2003,
<http://www.rfc-editor.org/info/rfc3471>.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
(GMPLS) Signaling Resource ReserVation Protocol-Traffic Switching (GMPLS) Signaling Resource ReserVation Protocol-
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<http://www.rfc-editor.org/info/rfc3473>.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009. Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
February 2009, <http://www.rfc-editor.org/info/rfc5420>.
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
Operations, Administration, and Maintenance (OAM) in MPLS "Requirements for Operations, Administration, and
Transport Networks", RFC 5860, May 2010. 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 [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, DOI 10.17487/RFC7260, June
2014, <http://www.rfc-editor.org/info/rfc7260>.
7.2. Informative References [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>.
[I-D.ietf-ccamp-rsvp-te-mpls-tp-oam-ext] 6.2. Informative References
Bellagamba, E., Takacs, A., Mirsky, G., Andersson, L.,
Skoldstrom, P., and D. Ward, "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-16 (work in
progress), January 2015.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<http://www.rfc-editor.org/info/rfc5920>.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations,
Maintenance Framework for MPLS-Based Transport Networks", Administration, and Maintenance Framework for MPLS-Based
RFC 6371, September 2011. Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
September 2011, <http://www.rfc-editor.org/info/rfc6371>.
[RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., [RFC6435] Boutros, S., Ed., Sivabalan, S., Ed., Aggarwal, R., Ed.,
and X. Dai, "MPLS Transport Profile Lock Instruct and Vigoureux, M., Ed., and X. Dai, Ed., "MPLS Transport
Loopback Functions", RFC 6435, November 2011. 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 Authors' Addresses
Jie Dong Jie Dong
Huawei Technologies Huawei Technologies
Huawei Campus, No.156 Beiqing Rd. Huawei Campus, No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: jie.dong@huawei.com Email: jie.dong@huawei.com
 End of changes. 54 change blocks. 
154 lines changed or deleted 168 lines changed or added

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