draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt   rfc6511.txt 
MPLS Working Group Z. Ali
G. Swallow Internet Engineering Task Force (IETF) Z. Ali
Internet Draft Cisco Systems, Inc. Request for Comments: 6511 G. Swallow
R. Aggarwal Category: Standards Track Cisco Systems
ISSN: 2070-1721 R. Aggarwal
Juniper Networks Juniper Networks
Intended status: Standard Track August 17, 2011 February 2012
Expires: February 16, 2012
Non Penultimate Hop Popping Behavior and out-of-band mapping for Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for
RSVP-TE Label Switched Paths RSVP-TE Label Switched Paths
draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt
Status of this Memo Abstract
This Internet-Draft is submitted in full conformance with the There are many deployment scenarios that require an egress Label
provisions of BCP 78 and BCP 79. Switching Router (LSR) to receive binding of the Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) Label Switched Path (LSP) to
an application and a payload identifier using some "out-of-band"
(OOB) mechanism. This document defines protocol mechanisms to
address this requirement. The procedures described in this document
are equally applicable for point-to-point (P2P) and point-to-
multipoint (P2MP) LSPs.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
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 is an Internet Standards Track document.
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 February 16, 2012. This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Copyright Notice 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/rfc6511.
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright Notice
Copyright (c) 2012 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.
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Abstract Table of Contents
There are many deployment scenarios which require Egress Label
Switching Router (LSR) to receive binding of the Resource
ReserVation Protocol Traffic Engineered (RSVP-TE) Label Switched
Path (LSP) to an application, and payload identification, using
some "out-of-band" (OOB) mechanism. This document defines
protocol mechanisms to address this requirement. The procedures
described in this document are equally applicable for point-to-
point (P2P) and point-to-multipoint (P2MP) LSPs.
Conventions used in this document
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].
Table of Contents
Copyright Notice ..............................................1
1. Introduction ...............................................3
2. RSVP-TE signaling extensions ...............................4
2.1. Signaling non-PHP behavior ............................4
2.2. Signaling OOB Mapping Indication ......................5
2.3. Relationship between OOB and non-PHP flags ............7
2.4. Egress Procedure for label binding ....................7
3. Security Considerations ....................................8
4. IANA Considerations ........................................8
4.1. Attribute Flags for LSP_ATTRIBUTES object .............8
4.2. New RSVP error sub-code ...............................9
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt 1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. RSVP-TE Signaling Extensions ....................................3
2.1. Signaling Non-PHP Behavior .................................3
2.2. Signaling OOB Mapping Indication ...........................5
2.3. Relationship between OOB and Non-PHP Flags .................6
2.4. Egress Procedure for Label Binding .........................6
3. Security Considerations .........................................7
4. IANA Considerations .............................................7
4.1. Attribute Flags for LSP Attributes Object ..................7
4.2. New RSVP Error Sub-Code ....................................8
5. Acknowledgements ................................................8
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................9
5. Acknowledgments ............................................9 1. Introduction
6. References .................................................9
6.1. Normative References ..................................9
6.2. Informative References ...............................10
1. Introduction When Resource Reservation Protocol - Traffic Engineering (RSVP-TE) is
used for applications like Multicast Virtual Private Network (MVPN)
[RFC6513] and Virtual Private LAN Service (VPLS) [RFC4761], an egress
Label Switching Router (LSR) receives the binding of the RSVP-TE
Label Switched Path (LSP) to an application and a payload identifier
using an "out-of-band" (OOB) mechanism (e.g., Border Gateway Protocol
(BGP)). In such cases, the egress LSR cannot make correct forwarding
decisions until such OOB mapping information is received.
Furthermore, in order to apply the binding information, the egress
LSR needs to identify the incoming LSP on which traffic is coming.
When Resource ReserVation Protocol Traffic Engineered (RSVP-TE) Therefore, non-Penultimate Hop Popping (non-PHP) behavior is required
is used for applications like Multicast Virtual Private Network to apply OOB mapping. Non-PHP behavior requires the egress LSRs to
(MVPN) [MVPN] and Virtual Private LAN Service (VPLS) [RFC4761], assign a non-NULL label for the LSP being signaled.
an Egress Label Switching Router (LSR) receives the binding of
the RSVP-TE Label Switched Path (LSP) to an application, and
payload identification, using an "out-of-band" (OOB) mechanism
(e.g., using Border Gateway Protocol (BGP)). In such cases, the
Egress LSR cannot make correct forwarding decision until such OOB
mapping information is received. Furthermore, in order to apply
the binding information, the Egress LSR needs to identify the
incoming LSP on which traffic is coming. Therefore, non
Penultimate Hop Popping (non-PHP) behavior is required to apply
OOB mapping. Non-PHP behavior requires the egress LSRs to assign
a non-NULL label for the LSP being signaled.
There are other applications that require non-PHP behavior. When There are other applications that require non-PHP behavior. When
RSVP-TE point-to-multipoint (P2MP) LSPs are used to carry IP RSVP-TE point-to-multipoint (P2MP) LSPs are used to carry IP
multicast traffic non-PHP behavior enables a leaf LSR to identify multicast traffic non-PHP behavior enables a leaf LSR to identify the
the P2MP TE LSP, on which traffic is received. Hence the egress P2MP TE LSP on which traffic is received. Hence, the egress LSR can
LSR can determine whether traffic is received on the expected P2MP determine whether traffic is received on the expected P2MP LSP and
LSP and discard traffic that is not received on the expected P2MP discard traffic that is not received on the expected P2MP LSP. Non-
LSP. Non-PHP behavior is also required to determine the context of PHP behavior is also required to determine the context of upstream
upstream assigned labels when the context is a MPLS LSP. Non-PHP assigned labels when the context is a MPLS LSP. Non-PHP behavior may
behavior may also be required for MPLS-TP LSPs [RFC5921]. also be required for MPLS Transport Profile (MPLS-TP) LSPs [RFC5921].
This document defines two new flags in the Attributes Flags TLV This document defines two new flags in the Attributes Flags TLV of
of the LSP_ATTRIBUTES object defined in [RFC5420]: one flag for the LSP Attributes object defined in [RFC5420]: one flag for
communication of non-PHP behavior, and one flag to indicate that communication of non-PHP behavior and one flag to indicate that the
the binding of the LSP to an application and payload identifier binding of the LSP to an application and a payload identifier
(payload-Id) needs to be learned via an out-of-band mapping (Payload ID) needs to be learned via an out-of-band mapping
mechanism. As there is one-to-one correspondence between bits in mechanism. As there is one-to-one correspondence between bits in the
the Attribute Flags TLV and the RRO Attributes subobject, Attribute Flags TLV and the Record Route Object (RRO) Attributes
corresponding flags to be carried in RRO Attributes subobject are subobject, corresponding flags to be carried in the RRO Attributes
also defined. subobject are also defined.
The procedures described in this document are equally applicable The procedures described in this document are equally applicable for
for P2P and P2MP LSPs. Specification of the OOB communication point-to-point (P2P) and P2MP LSPs. Specification of the OOB
mechanism(s) is beyond the scope of this document. communication mechanism(s) is beyond the scope of this document.
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt 1.1. Conventions Used in This Document
2. RSVP-TE signaling extensions 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].
This section describes the signaling extensions required to 2. RSVP-TE Signaling Extensions
address the above-mentioned requirements.
2.1. Signaling non-PHP behavior This section describes the signaling extensions required to address
the above-mentioned requirements.
In order to request non-PHP behavior for an RSVP-TE LSP, this 2.1. Signaling Non-PHP Behavior
document defines a new flag in the Attributes Flags TLV of the
LSP_ATTRIBUTES object defined in [RFC5420]:
Bit Number (to be assigned by IANA): non-PHP behavior requested flag. In order to request non-PHP behavior for an RSVP-TE LSP, this
document defines a new flag in the Attributes Flags TLV of the LSP
Attributes object defined in [RFC5420]:
In order to indicate to the Ingress LSR that the Egress LSR Bit Number 7: Non-PHP behavior flag
recognizes the "non-PHP behavior requested flag", the following
new bit is defined in the Flags field of the Record Route object
(RRO) Attributes subobject:
Bit Number (same as bit number assigned for non-PHP behavior In order to indicate to the ingress LSR that the egress LSR
requested flag): Non-PHP behavior acknowledgement flag. recognizes the "Non-PHP behavior flag", the same bit is used in the
Flags field of the Record Route Object (RRO) Attributes subobject.
An Ingress LSR sets the "non-PHP behavior requested flag" to An ingress LSR sets the "Non-PHP behavior flag" to signal that the
signal the egress LSRs SHOULD assign non-NULL label for the LSP egress LSRs SHOULD assign a non-NULL label for the LSP being
being signaled. This flag MUST NOT be modified by any other LSRs signaled. This flag MUST NOT be modified by any other LSRs in the
in the network. LSRs other than the Egress LSRs SHOULD ignore network. LSRs other than the egress LSRs SHOULD ignore this flag.
this flag.
If an egress LSR receiving the Path message, supports the If an egress LSR receiving the Path message supports the LSP
LSP_ATTRIBUTES object and the Attributes Flags TLV, and also Attributes object and the Attributes Flags TLV and also recognizes
recognizes the "non-PHP behavior requested flag", it MUST the "Non-PHP behavior flag", it MUST allocate a non-NULL local label.
allocate a non-NULL local label. The egress LSR MUST also set the The egress LSR MUST also set the "Non-PHP behavior flag" in the Flags
"Non-PHP behavior acknowledgement flag" in the Flags field of the field of the RRO Attributes subobject.
RRO Attribute subobject.
If the egress LSR If the egress LSR
- supports the LSP_ATTRIBUTES object but does not recognize the - supports the LSP Attributes object but does not recognize the
Attributes Flags TLV; or Attributes Flags TLV; or
- supports the LSP_ATTRIBUTES object and recognize the Attributes
Flags TLV, but does not recognize the "non-PHP behavior requested
flag";
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt - supports the LSP Attributes object and recognizes the Attributes
Flags TLV, but does not recognize the "Non-PHP behavior flag";
then it silently ignores this request according to the processing then it silently ignores the request according to the processing
rules of [RFC5420]. rules of [RFC5420].
An ingress LSR requesting non-PHP behavior SHOULD examine "Non- An ingress LSR requesting non-PHP behavior SHOULD examine the "Non-
PHP behavior acknowledgement flag" in the Flags field of the RRO PHP behavior flag" in the Flags field of the RRO Attributes subobject
Attribute subobject and MAY send a Path Tear to the Egress which and MAY send a Path Tear to the egress, which has not set the "Non-
has not set the "Non-PHP behavior acknowledgement flag". An PHP behavior flag". An ingress LSR requesting non-PHP behavior MAY
ingress LSR requesting non-PHP behavior MAY also examine the also examine the label value corresponding to the egress LSR(s) in
label value corresponding to the Egress LSR(s) in the RRO, and the RRO and MAY send a Path Tear to the egress, which assigns a NULL
MAY send a Path Tear to the Egress which assigns a Null label label value.
value.
When signaling a P2MP LSP, a source node may wish to solicit When signaling a P2MP LSP, a source node may wish to solicit an
individual response to the "non-PHP behavior requested flag" from individual response to the "Non-PHP behavior flag" from the leaf
the leaf nodes. Given the constraints on how the LSP_ATTRIBUTES may nodes. Given the constraints on how the LSP Attributes may be
be carried in Path and Resv Messages according to RFC5420, in carried in Path and Resv messages according to [RFC5420], in this
this situation the source node MUST use a separate Path message for situation, the source node MUST use a separate Path message for each
each leaf in networks where [ATTRIBUTE-BNF] is not supported. In leaf in networks where [RFC6510] is not supported. In networks with
networks with [ATTRIBUTE-BNF] deployed either separate Path [RFC6510] deployed, either a single leaf per Path message or multiple
message for each leaf or multiple leafs per Path message MAY be leaves per Path message MAY be used by the source node.
used by the source node.
2.2. Signaling OOB Mapping Indication 2.2. Signaling OOB Mapping Indication
This document defines a single flag to indicate that the normal This document defines a single flag to indicate that the normal
binding mechanism of an RSVP session is overridden. The actual binding mechanism of an RSVP session is overridden. The actual out-
out-of-band mappings are beyond the scope of this document. The of-band mappings are beyond the scope of this document. The flag is
flag is carried in the Attributes Flags TLV of the LSP_ATTRIBUTES carried in the Attributes Flags TLV of the LSP Attributes object
object defined in [RFC5420] and is defined as follows: defined in [RFC5420] and is defined as follows:
Bit Number (to be assigned by IANA): OOB mapping indication flag.
In order to indicate to the Ingress LSR that the Egress LSR
recognizes the "OOB mapping indication flag", the following new
bit is defined in the Flags field of the Record Route object
(RRO) Attributes subobject:
Bit Number (same as bit number assigned for OOB mapping Bit Number 8: OOB mapping flag
indication flag): OOB mapping acknowledgement flag.
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt In order to indicate to the ingress LSR that the egress LSR
recognizes the "OOB mapping flag", the following same bit is used in
the Flags field of the Record Route object (RRO) Attributes
subobject.
An Ingress LSR sets the OOB mapping indication flag to signal the An ingress LSR sets the "OOB mapping flag" to signal the egress LSR
Egress LSR that binding of RSVP-TE LSP to an application and that the binding of RSVP-TE LSP to an application and a payload
payload identification is being signaled out-of-band. This flag identifier is being signaled out-of-band. This flag MUST NOT be
MUST NOT be modified by any other LSRs in the network. LSRs modified by any other LSRs in the network. LSRs other than the
other than the Egress LSRs SHOULD ignore this flag. egress LSRs SHOULD ignore this flag.
When an Egress LSR which supports the "OOB mapping indication When an egress LSR that supports the "OOB mapping flag" receives a
flag", receives a Path message with that flag set, the Egress LSR Path message with that flag set, the egress LSR MUST set the "OOB
MUST set the "OOB mapping acknowledgement flag" in the Flags mapping flag" in the Flags field of the RRO Attributes subobject.
field of the RRO Attribute subobject. The rest of the RSVP The rest of the RSVP signaling proceeds as normal. However, the LSR
signaling proceeds as normal. However, the LSR MUST have MUST have received the OOB mapping before accepting traffic on the
received the OOB mapping before accepting traffic on the LSP. LSP. This implies that the egress LSR MUST NOT set up forwarding
This implies that the Egress LSR MUST NOT setup forwarding state state for the LSP before it receives the OOB mapping.
for the LSP before it receives the OOB mapping.
Note that the payload information SHOULD be supplied by the OOB Note that the payload information SHOULD be supplied by the OOB
mapping. If the egress LSR receives the payload information from mapping. If the egress LSR receives the payload information from OOB
OOB mapping then the LSR MUST ignore L3PID in the Label Request mapping, then the LSR MUST ignore the L3PID (Layer 3 Protocol ID) in
Object [RFC3209]. the Label Request Object [RFC3209].
If the egress LSR If the egress LSR
- supports the LSP_ATTRIBUTES object but does not recognize the - supports the LSP Attributes object but does not recognize the
Attributes Flags TLV; or Attributes Flags TLV; or
- supports the LSP_ATTRIBUTES object and recognizes the - supports the LSP Attributes object and recognizes the Attributes
Attributes Flags TLV, but does not recognize the "OOB mapping Flags TLV, but does not recognize the "OOB mapping flag";
indication flag";
then it silently ignores this request according to the processing then it silently ignores the request according to the processing
rules of [RFC5420]. rules of [RFC5420].
An ingress LSR requesting OOB mapping SHOULD examine "OOB mapping An ingress LSR requesting OOB mapping SHOULD examine the "OOB mapping
acknowledgement flag" in the Flags field of the RRO Attribute flag" in the Flags field of the RRO Attributes subobject and MAY send
subobject and MAY send a Path Tear to the Egress which has not a Path Tear to the egress, which has not set the "OOB mapping flag".
set the "OOB mapping acknowledgement flag".
When signaling a P2MP LSP, a source node may wish to solicit
individual response to the "OOB mapping indication flag" from the
the leaf nodes. Given the constraints on how the LSP_ATTRIBUTES
may be carried in Path and Resv Messages according to RFC5420, in
this situation the source node MUST use a separate Path message for
each leaf in networks where [ATTRIBUTE-BNF] is not supported. In
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt
networks with [ATTRIBUTE-BNF] deployed either separate Path When signaling a P2MP LSP, a source node may wish to solicit an
message for each leaf or multiple leafs per Path message MAY be individual response to the "OOB mapping flag" from the leaf nodes.
used by the source node. Given the constraints on how the LSP Attributes object may be carried
in Path and Resv messages according to [RFC5420], in this situation,
the source node MUST use a separate Path message for each leaf in
networks where [RFC6510] is not supported. In networks with
[RFC6510] deployed, either a single leaf per Path message or multiple
leaves per Path message MAY be used by the source node.
In deploying applications where Egress LSR receives the binding In deploying applications where the egress LSR receives the binding
of the RSVP-TE LSP to an application, and payload identification, of the RSVP-TE LSP to an application and a payload identifier using
using OOB mechanism, it is important to recognize that the OOB an OOB mechanism, it is important to recognize that the OOB mapping
mapping is sent asynchronously with respect to the signaling of is sent asynchronously with respect to the signaling of RSVP-TE LSP.
RSVP-TE LSP. Egress LSR only installs forwarding state for the LSP The egress LSR only installs forwarding state for the LSP after it
after it receives the OOB mapping. In deploying applications using receives the OOB mapping. In deploying applications using an OOB
OOB mechanism, an Ingress LSR may need to know when the Egress is mechanism, an ingress LSR may need to know when the egress is
properly setup for forwarding (i.e., has received the OOB mapping). properly set up for forwarding (i.e., has received the OOB mapping).
How the Ingress LSR determines that the LSR is properly setup for How the ingress LSR determines that the LSR is properly set up for
forwarding at the Egress LSR is beyond the scope of this document. forwarding at the egress LSR is beyond the scope of this document.
Nonetheless, if the OOB mapping is not received by the Egress LSR Nonetheless, if the OOB mapping is not received by the egress LSR
within a reasonable time, the procedure defined in section 2.4 to within a reasonable time, the procedure defined in Section 2.4 to
tear down the LSP is followed. tear down the LSP is followed.
2.3. Relationship between OOB and non-PHP flags 2.3. Relationship between OOB and Non-PHP Flags
"Non-PHP behavior desired" and "OOB mapping indication" flags can The "Non-PHP behavior flag" and "OOB mapping flag" can appear and be
appear and be processed independently of each other. However, as processed independently of each other. However, as mentioned
mentioned earlier, in the context of the applications discussed in earlier, in the context of the applications discussed in this
this document, OOB mapping requires non-PHP behavior. An Ingress document, OOB mapping requires non-PHP behavior. An ingress LSR
LSR requesting the OOB mapping MAY also set the "non-PHP behavior requesting the OOB mapping MAY also set the "Non-PHP behavior flag"
requested flag" in the LSP_ATTRIBUTES object in the Path message. in the LSP Attributes object in the Path message.
2.4. Egress Procedure for label binding 2.4. Egress Procedure for Label Binding
RSVP-TE signaling completion and the OOB mapping information RSVP-TE signaling completion and the OOB mapping information
reception happen asynchronously at the Egress. As mentioned in reception happen asynchronously at the egress. As mentioned in
Section 2.2, Egress waits for the OOB mapping before accepting Section 2.2, egress waits for the OOB mapping before accepting
traffic on the LSP. Nonetheless, MPLS OAM mechanisms, e.g., LSP traffic on the LSP. Nonetheless, MPLS Operations, Administration,
Ping and Trace route as defined in [RFC4379], [P2MP-OAM], are and Maintenance (OAM) mechanisms, e.g., LSP ping and traceroute, as
expected to work independent of OOB mapping learning process. defined in [RFC4379] and [RFC6425], are expected to work
independently of OOB mapping learning process.
In order to avoid unnecessary use of the resources and possible In order to avoid unnecessary use of the resources and possible
black-holing of traffic, an Egress LSR MAY send a Path Error black-holing of traffic, an egress LSR MAY send a Path Error message
message if the OOB mapping information is not received within a if the OOB mapping information is not received within a reasonable
reasonable time. This Path Error message SHOULD include the error time. This Path Error message SHOULD include the error code/sub-code
code/sub-code "Notify Error/ no OOB mapping received" for all "Notify Error / no OOB mapping received" for all affected LSPs. If a
affected LSPs. If notify request was included when the LSP was notify request was included when the LSP was initially set up, a
initially setup, Notify message (as defined in [RFC3473]) MAY Notify message (as defined in [RFC3473]) MAY also be used for
also be used for delivery of this information to the Ingress LSR. delivery of this information to the ingress LSR. An egress LSR MAY
An Egress LSR MAY implement a cleanup timer for this purpose. The implement a cleanup timer for this purpose. The time-out value is a
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt local decision at the egress, with a RECOMMENDED default value of 60
seconds.
time-out value is a local decision at the Egress, with a
RECOMMENDED default value of 60 seconds.
3. Security Considerations 3. Security Considerations
Addition of "non-PHP behavior" adds a variable of attacks on the The addition of non-PHP behavior adds a variety of attacks on the
label assigned by the Egress node. As change in the value of the label assigned by the egress node. As change in the value of the
egress label reported in the RRO can cause the LSP to be torn egress label reported in the RRO can cause the LSP to be torn down,
down, additional security considerations for protecting label additional security considerations for protecting labels assigned by
assigned by the Egress node are required. Security mechanisms as the egress node are required. Security mechanisms as identified in
identified in [RFC5920], [RFC2205], [RFC3209], [RFC3473], [RFC5920], [RFC2205], [RFC3209], [RFC3473], [RFC5420], and [RFC4875]
[RFC5420] and [RFC4875] can be used for this purpose. This can be used for this purpose. This document does not introduce any
document does not introduce any additional security issues above additional security issues above those identified in [RFC5920],
those identified in [RFC5920], [RFC2205], [RFC3209], [RFC3473], [RFC2205], [RFC3209], [RFC3473], [RFC5420], and [RFC4875].
[RFC5420] and [RFC4875].
4. IANA Considerations 4. IANA Considerations
The following changes to the Resource Reservation Protocol-Traffic The following changes to the Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) Parameters registry are required. Engineering (RSVP-TE) Parameters registry are required.
4.1. Attribute Flags for LSP_ATTRIBUTES object 4.1. Attribute Flags for LSP Attributes Object
The following new flags are defined for the Attributes Flags TLV in
the LSP Attributes object.
The following new flags are defined for the Attributes Flags TLV
in the LSP_ATTRIBUTES object. The numeric values are to be
assigned by IANA.
o Non-PHP behavior flag: o Non-PHP behavior flag:
This flags is used in the Attributes Flags TLV in a Path message.
The flags have corresponding new flag to be used in the RRO
Attributes subobject. As per [RFC5420], the bit numbering in the
Attribute Flags TLV and the RRO Attributes subobject is
identical. That is, the same attribute is indicated by the same
bit in both places. This flag is not allowed in the Attributes
Flags TLV in a Resv message. Specifically, Attributes of this
flag are as follows:
- Bit Number: To be assigned by IANA. This flag is used in the Attributes Flags TLV in a Path message.
The flag has a corresponding new flag to be used in the RRO
Attributes subobject. As per [RFC5420], the bit numbering in the
Attribute Flags TLV and the RRO Attributes subobject is identical.
That is, the same attribute is indicated by the same bit in both
places. This flag is not allowed in the Attributes Flags TLV in a
Resv message. Specifically, attributes of this flag are as
follows:
- Attribute flag carried in Path message: Yes - Bit Number: 7
- Attribute flag carried in Resv message: No - Attribute flag carried in Path message: Yes
- Attribute flag carried in RRO message: Yes - Attribute flag carried in Resv message: No
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt - Attribute flag carried in RRO message: Yes
o OOB mapping flag: o OOB mapping flag:
This flags is used in the Attributes Flags TLV in a Path message. This flag is used in the Attributes Flags TLV in a Path message.
The flags have corresponding new flag to be used in the RRO The flag has a corresponding new flag to be used in the RRO
Attributes subobject. As per [RFC5420], the bit numbering in the Attributes subobject. As per [RFC5420], the bit numbering in the
Attribute Flags TLV and the RRO Attributes subobject is Attribute Flags TLV and the RRO Attributes subobject is identical.
identical. That is, the same attribute is indicated by the same That is, the same attribute is indicated by the same bit in both
bit in both places. This flag is not allowed in the Attributes places. This flag is not allowed in the Attributes Flags TLV in a
Flags TLV in a Resv message. Specifically, Attributes of this Resv message. Specifically, attributes of this flag are as
flag are as follows: follows:
- Bit Number: To be assigned by IANA. - Bit Number: 8
- 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 message: Yes - Attribute flag carried in RRO message: Yes
4.2. New RSVP error sub-code 4.2. New RSVP Error Sub-Code
For Error Code = 25 "Notify Error" (see [RFC3209]) the following For Error Code = 25 "Notify Error" (see [RFC3209]), the following
sub-code is defined. sub-code is defined.
Sub-code Value Sub-code Value
-------- ----- -------- -----
No OOB mapping received to be assigned by IANA.
5. Acknowledgments No OOB mapping received 12
The authors would like to thank Yakov Rekhter for his suggestions 5. Acknowledgements
on the draft.
6. References The authors would like to thank Yakov Rekhter for his suggestions on
this document.
6.1. Normative References 6. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6.1. Normative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5420] A. Farrel, D. Papadimitriou, J. P. Vasseur and A. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Ayyangar, "Encoding of Attributes for Multiprotocol Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Label Switching (MPLS) Label Switched Path (LSP) Functional Specification", RFC 2205, September 1997.
Establishment Using RSVP-TE", RFC 5420, February 2006.
[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, [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, December 2001.
[RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et al, [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
"Extensions to RSVP-TE for Point-to-Multipoint TE Switching (GMPLS) Signaling Resource ReserVation Protocol-
LSPs", RFC 4875. Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Switching (GMPLS) Signaling Resource ReserVation Yasukawa, Ed., "Extensions to Resource Reservation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC Protocol - Traffic Engineering (RSVP-TE) for Point-to-
3473, January 2003.. Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
2007.
[RFC2205] R. Braden, Ed., "Resource ReSerVation Protocol (RSVP) - [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
- Version 1 Functional Specification", RFC 2205, Ayyangarps, "Encoding of Attributes for MPLS LSP
September 1997. Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009.
[ATTRIBUTE-BNF] Berger, L. and Swallow, G., "LSP Attributes Related [RFC6510] Berger, L. and G. Swallow, "Resource Reservation Protocol
Routing Backus-Naur Form", draft-ietf-ccamp-attribute- (RSVP) Message Formats for Label Switched Path (LSP)
bnf, work in progress. Attributes Objects", RFC 6510, February 2012.
6.2. Informative References 6.2. Informative References
[MVPN] E. Rosen, R. Aggarwal et al, "Multicast in MPLS/BGP IP [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
VPNs", draft-ietf-l3vpn-2547bis-mcast-10.txt, work in Label Switched (MPLS) Data Plane Failures", RFC 4379,
progress. February 2006.
[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
Private LAN Service (VPLS) Using BGP for Auto-Discovery LAN Service (VPLS) Using BGP for Auto-Discovery and
and Signaling", RFC 4761, January 2007. Signaling", RFC 4761, January 2007.
[RFC5921] M. Bocci, S. Bryant, et al, "A Framework for [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
MPLS in Transport Networks", RFC 5921, January 2007. Networks", RFC 5920, July 2010.
[RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
Networks", RFC 5920, July 2010. L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, July 2010.
Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
Failures in Point-to-Multipoint MPLS - Extensions to LSP
Ping", RFC 6425, November 2011.
[RFC4379] K. Kompella, and G. Swallow, "Detecting Multi-Protocol [RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
Label Switched (MPLS) Data Plane Failures", RFC 4379, MPLS/BGP IP VPNs", RFC 6513, February 2012.
February 2006.
[P2MP-OAM] S. Saxena, Ed., G. Swallow, Z. Ali, A. Farrel, S.
Yasukawa, T. Nadeau, "Detecting Data Plane Failures in
Point-to-Multipoint Multiprotocol Label Switching
(MPLS) - Extensions to LSP Ping", draft-ietf-mpls-p2mp-
lsp-ping-17.txt, work in progress.
Author's Addresses Authors' Addresses
Zafar Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
Email: zali@cisco.com EMail: zali@cisco.com
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
Email: swallow@cisco.com EMail: swallow@cisco.com
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
rahul@juniper.net EMail: raggarwa_1@yahoo.com
 End of changes. 96 change blocks. 
339 lines changed or deleted 300 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/