draft-ietf-mpls-3209-patherr-04.txt   draft-ietf-mpls-3209-patherr-05.txt 
Networking Working Group JP. Vasseur, Ed. Networking Working Group JP. Vasseur, Ed.
Internet-Draft George. Swallow Internet-Draft George. Swallow
Intended status: BCP Cisco Systems, Inc Intended status: BCP Cisco Systems, Inc
Expires: August 6, 2009 Ina. Minei Expires: January 30, 2010 Ina. Minei
Juniper Networks Juniper Networks
February 2, 2009 July 29, 2009
Node behavior upon originating and receiving Resource ReserVation Node behavior upon originating and receiving Resource ReserVation
Protocol (RSVP) Path Error message Protocol (RSVP) Path Error message
draft-ietf-mpls-3209-patherr-04.txt draft-ietf-mpls-3209-patherr-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 6, 2009. This Internet-Draft will expire on January 30, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
The aim of this document is to describe a common practice with regard The aim of this document is to describe a common practice with regard
to the behavior of a node sending a Resource ReserVation Protocol to the behavior of a node sending a Resource ReserVation Protocol
(RSVP) Traffic Engineering (TE) Path Error message and to the (RSVP) Traffic Engineering (TE) Path Error message and to the
behavior of a node receiving an RSVP Path Error message for a behavior of a node receiving an RSVP Path Error message for a
preempted Multi-Protocol Label Switching (MPLS) Traffic Engineering preempted Multi-Protocol Label Switching (MPLS) and Generalized MPLS
Label Switched Path (TE LSP). This document does not define any new (GMPLS) Traffic Engineering Label Switched Path (TE LSP). This
protocol extensions. document does not define any new protocol extensions.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol behavior . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol behavior . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Behavior at Detecting Nodes . . . . . . . . . . . . . . . . 4 2.1. Behavior at Detecting Nodes . . . . . . . . . . . . . . . . 4
2.2. Behavior at Receiving Nodes . . . . . . . . . . . . . . . . 5 2.2. Behavior at Receiving Nodes . . . . . . . . . . . . . . . . 4
2.3. Data Plane Behavior . . . . . . . . . . . . . . . . . . . . 5 2.3. Data Plane Behavior . . . . . . . . . . . . . . . . . . . . 5
3. RSVP PathErr Messages For a Preempted TE LSP . . . . . . . . . 5 3. RSVP PathErr Messages For a Preempted TE LSP . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
The aim of this document is to describe a common practice with regard The aim of this document is to describe a common practice with regard
to the behavior of a node sending a Resource ReserVation Protocol to the behavior of a node sending a Resource ReserVation Protocol
(RSVP) Traffic Engineering (TE) Path Error message and to the (RSVP) Traffic Engineering (TE) Path Error message and to the
behavior of a node receiving an RSVP Path Error message for a behavior of a node receiving an RSVP Path Error message for a
preempted Multi-Protocol Label Switching (MPLS) Traffic Engineering preempted Multi-Protocol Label Switching (MPLS) and Generalized MPLS
Label Switched Path (TE LSP). (GMPLS) Traffic Engineering Label Switched Path (TE LSP).
[RFC2205] defines two RSVP error message types: PathErr and ResvErr [RFC2205] defines two RSVP error message types: PathErr and ResvErr
that are generated when an error occurs. Path Error Messages that are generated when an error occurs. Path Error Messages
(PathErr) are used to report errors and travel upstream toward the (PathErr) are used to report errors and travel upstream toward the
head-end of the flow. Resv Error messages (ResvErr) travel head-end of the flow. Resv Error messages (ResvErr) travel
downstream toward the tail-end of the flow. downstream toward the tail-end of the flow.
This document describes only PathErr message processing for the This document describes only PathErr message processing for the
specific case of a preempted Traffic Engineering Label Switched Path specific case of a preempted Traffic Engineering Label Switched Path
(TE LSP) where the term preemption is defined in [RFC3209]. (TE LSP) where the term preemption is defined in [RFC3209].
skipping to change at page 3, line 34 skipping to change at page 3, line 34
2. Protocol behavior 2. Protocol behavior
PathErr messages are routed hop-by-hop using the path state PathErr messages are routed hop-by-hop using the path state
established when a Path message is routed through the network from established when a Path message is routed through the network from
the head-end to its tail-end. the head-end to its tail-end.
As stated in [RFC2205], PathErr messages do not modify the state of As stated in [RFC2205], PathErr messages do not modify the state of
any node through which they pass; they are only reported to the head- any node through which they pass; they are only reported to the head-
end of the TE LSP (Traffic Engineering Label Switched Path). end of the TE LSP (Traffic Engineering Label Switched Path).
The format of the PathErr message as defined in [RFC2205] is as The format of the PathErr message as defined in [RFC2205].
follows:
<PathErr message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC>
[ <POLICY_DATA> ...]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
The ERROR_SPEC object includes the IP address of the node that The ERROR_SPEC object includes the IP address of the node that
detected the error (Error Node Address), and specifies the error detected the error (Error Node Address), and specifies the error
through two fields. The Error Code field encodes the category of the through two fields. The Error Code field encodes the category of the
error, for example, Policy Control Failure or Unknown object class. error, for example, Policy Control Failure or Unknown object class.
The Error Value field qualifies the error code to indicate the error The Error Value field qualifies the error code to indicate the error
with more precision. [RFC3209] extends RSVP as defined in [RFC2205] with more precision. [RFC3209] extends RSVP as defined in [RFC2205]
for the management of Multi-Protocol Label Switching (MPLS) Traffic for the management of Multi-Protocol Label Switching (MPLS) Traffic
Engineered Label Switched Paths (TE-LSPs). [RFC3209] specifies Engineered Label Switched Paths (TE-LSPs). [RFC3209] specifies
several additional conditions that trigger the sending of a RSVP several additional conditions that trigger the sending of a RSVP
skipping to change at page 4, line 24 skipping to change at page 4, line 14
[RFC2205], [RFC3209], and other documents are maintained in a [RFC2205], [RFC3209], and other documents are maintained in a
registry by the IANA. registry by the IANA.
The error conditions fall into two categories: The error conditions fall into two categories:
o Fatal errors represent disruptive conditions for a TE LSP, o Fatal errors represent disruptive conditions for a TE LSP,
o Non-fatal errors are non-disruptive conditions which have occurred o Non-fatal errors are non-disruptive conditions which have occurred
for this TE LSP for this TE LSP
Additionally, PathErr messages may be used in two circumstances: PathErr messages may be used in two circumstances:
o During TE LSP establishment, o During TE LSP establishment,
o After a TE LSP has been successfully established. o After a TE LSP has been successfully established.
Nodal behavior is dependent on which combination of the four cases Nodal behavior is dependent on which combination of the four cases
listed above applies. The following sections describe the expected listed above applies. The following sections describe the expected
behavior at nodes that perform a preemption action for a TE LSP (and behavior at nodes that perform a preemption action for a TE LSP (and
therefore report using error PathErr messages), and at nodes that therefore report using error PathErr messages), and at nodes that
receive PathErr messages. This text is a clarification and re- receive PathErr messages. This text is a clarification and re-
 End of changes. 11 change blocks. 
27 lines changed or deleted 17 lines changed or added

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