diff options
Diffstat (limited to 'doc/rfc/rfc6511.txt')
| -rw-r--r-- | doc/rfc/rfc6511.txt | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc6511.txt b/doc/rfc/rfc6511.txt new file mode 100644 index 0000000..41e93a1 --- /dev/null +++ b/doc/rfc/rfc6511.txt @@ -0,0 +1,563 @@ + + + + + + +Internet Engineering Task Force (IETF) Z. Ali +Request for Comments: 6511 G. Swallow +Category: Standards Track Cisco Systems +ISSN: 2070-1721 R. Aggarwal + Juniper Networks + February 2012 + + + Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for + RSVP-TE Label Switched Paths + +Abstract + + There are many deployment scenarios that require an egress Label + 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. + +Status of This Memo + + This is an Internet Standards Track document. + + 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. + + 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 Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + + + + + +Ali, et al. Standards Track [Page 1] + +RFC 6511 Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012 + + + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + Table of Contents + + 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 + +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. + + + + +Ali, et al. Standards Track [Page 2] + +RFC 6511 Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012 + + + 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 + RSVP-TE point-to-multipoint (P2MP) LSPs are used to carry IP + multicast traffic non-PHP behavior enables a leaf LSR to identify the + P2MP TE LSP on which traffic is received. Hence, the egress LSR can + determine whether traffic is received on the expected P2MP LSP and + discard traffic that is not received on the expected P2MP LSP. Non- + PHP behavior is also required to determine the context of upstream + assigned labels when the context is a MPLS LSP. Non-PHP behavior may + also be required for MPLS Transport Profile (MPLS-TP) LSPs [RFC5921]. + + This document defines two new flags in the Attributes Flags TLV of + the LSP Attributes object defined in [RFC5420]: one flag for + communication of non-PHP behavior and one flag to indicate that the + binding of the LSP to an application and a payload identifier + (Payload ID) needs to be learned via an out-of-band mapping + mechanism. As there is one-to-one correspondence between bits in the + Attribute Flags TLV and the Record Route Object (RRO) Attributes + subobject, corresponding flags to be carried in the RRO Attributes + subobject are also defined. + + The procedures described in this document are equally applicable for + point-to-point (P2P) and P2MP LSPs. Specification of the OOB + communication mechanism(s) is beyond the scope of this document. + +1.1. 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]. + +2. RSVP-TE Signaling Extensions + + This section describes the signaling extensions required to address + the above-mentioned requirements. + +2.1. Signaling Non-PHP Behavior + + 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]: + + Bit Number 7: Non-PHP behavior flag + + + + + +Ali, et al. Standards Track [Page 3] + +RFC 6511 Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012 + + + In order to indicate to the ingress LSR that the egress LSR + 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 flag" to signal that the + egress LSRs SHOULD assign a non-NULL label for the LSP being + signaled. This flag MUST NOT be modified by any other LSRs in the + network. LSRs other than the egress LSRs SHOULD ignore this flag. + + If an egress LSR receiving the Path message supports the LSP + Attributes object and the Attributes Flags TLV and also recognizes + the "Non-PHP behavior flag", it MUST allocate a non-NULL local label. + The egress LSR MUST also set the "Non-PHP behavior flag" in the Flags + field of the RRO Attributes subobject. + + If the egress LSR + + - supports the LSP Attributes object but does not recognize the + Attributes Flags TLV; or + + - supports the LSP Attributes object and recognizes the Attributes + Flags TLV, but does not recognize the "Non-PHP behavior flag"; + + then it silently ignores the request according to the processing + rules of [RFC5420]. + + An ingress LSR requesting non-PHP behavior SHOULD examine the "Non- + PHP behavior flag" in the Flags field of the RRO Attributes subobject + and MAY send a Path Tear to the egress, which has not set the "Non- + PHP behavior flag". An ingress LSR requesting non-PHP behavior MAY + also examine the label value corresponding to the egress LSR(s) in + the RRO and MAY send a Path Tear to the egress, which assigns a NULL + label value. + + When signaling a P2MP LSP, a source node may wish to solicit an + individual response to the "Non-PHP behavior flag" from 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 [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. + + + + + + + + + +Ali, et al. Standards Track [Page 4] + +RFC 6511 Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012 + + +2.2. Signaling OOB Mapping Indication + + This document defines a single flag to indicate that the normal + binding mechanism of an RSVP session is overridden. The actual out- + of-band mappings are beyond the scope of this document. The flag is + carried in the Attributes Flags TLV of the LSP Attributes object + defined in [RFC5420] and is defined as follows: + + Bit Number 8: OOB mapping flag + + 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 flag" to signal the egress LSR + that the binding of RSVP-TE LSP to an application and a payload + identifier is being signaled out-of-band. This flag MUST NOT be + modified by any other LSRs in the network. LSRs other than the + egress LSRs SHOULD ignore this flag. + + When an egress LSR that supports the "OOB mapping flag" receives a + Path message with that flag set, the egress LSR MUST set the "OOB + mapping flag" in the Flags field of the RRO Attributes subobject. + The rest of the RSVP signaling proceeds as normal. However, the LSR + MUST have received the OOB mapping before accepting traffic on the + LSP. This implies that the egress LSR MUST NOT set up forwarding + state for the LSP before it receives the OOB mapping. + + Note that the payload information SHOULD be supplied by the OOB + mapping. If the egress LSR receives the payload information from OOB + mapping, then the LSR MUST ignore the L3PID (Layer 3 Protocol ID) in + the Label Request Object [RFC3209]. + + If the egress LSR + + - supports the LSP Attributes object but does not recognize the + Attributes Flags TLV; or + + - supports the LSP Attributes object and recognizes the Attributes + Flags TLV, but does not recognize the "OOB mapping flag"; + + then it silently ignores the request according to the processing + rules of [RFC5420]. + + An ingress LSR requesting OOB mapping SHOULD examine the "OOB mapping + flag" in the Flags field of the RRO Attributes subobject and MAY send + a Path Tear to the egress, which has not set the "OOB mapping flag". + + + +Ali, et al. Standards Track [Page 5] + +RFC 6511 Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012 + + + When signaling a P2MP LSP, a source node may wish to solicit an + individual response to the "OOB mapping flag" from the leaf nodes. + 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 the egress LSR receives the binding + of the RSVP-TE LSP to an application and a payload identifier using + an OOB mechanism, it is important to recognize that the OOB mapping + is sent asynchronously with respect to the signaling of RSVP-TE LSP. + The egress LSR only installs forwarding state for the LSP after it + receives the OOB mapping. In deploying applications using an OOB + mechanism, an ingress LSR may need to know when the egress is + properly set up for forwarding (i.e., has received the OOB mapping). + 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. + Nonetheless, if the OOB mapping is not received by the egress LSR + within a reasonable time, the procedure defined in Section 2.4 to + tear down the LSP is followed. + +2.3. Relationship between OOB and Non-PHP Flags + + The "Non-PHP behavior flag" and "OOB mapping flag" can appear and be + processed independently of each other. However, as mentioned + earlier, in the context of the applications discussed in this + document, OOB mapping requires non-PHP behavior. An ingress LSR + requesting the OOB mapping MAY also set the "Non-PHP behavior flag" + in the LSP Attributes object in the Path message. + +2.4. Egress Procedure for Label Binding + + RSVP-TE signaling completion and the OOB mapping information + reception happen asynchronously at the egress. As mentioned in + Section 2.2, egress waits for the OOB mapping before accepting + traffic on the LSP. Nonetheless, MPLS Operations, Administration, + and Maintenance (OAM) mechanisms, e.g., LSP ping and traceroute, as + 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 + black-holing of traffic, an egress LSR MAY send a Path Error message + if the OOB mapping information is not received within a reasonable + time. This Path Error message SHOULD include the error code/sub-code + "Notify Error / no OOB mapping received" for all affected LSPs. If a + notify request was included when the LSP was initially set up, a + + + +Ali, et al. Standards Track [Page 6] + +RFC 6511 Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012 + + + Notify message (as defined in [RFC3473]) MAY also be used for + delivery of this information to the ingress LSR. An egress LSR MAY + implement a cleanup timer for this purpose. The time-out value is a + local decision at the egress, with a RECOMMENDED default value of 60 + seconds. + +3. Security Considerations + + 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 + egress label reported in the RRO can cause the LSP to be torn down, + additional security considerations for protecting labels assigned by + the egress node are required. Security mechanisms as identified in + [RFC5920], [RFC2205], [RFC3209], [RFC3473], [RFC5420], and [RFC4875] + can be used for this purpose. This document does not introduce any + additional security issues above those identified in [RFC5920], + [RFC2205], [RFC3209], [RFC3473], [RFC5420], and [RFC4875]. + +4. IANA Considerations + + The following changes to the Resource Reservation Protocol - Traffic + Engineering (RSVP-TE) Parameters registry are required. + +4.1. Attribute Flags for LSP Attributes Object + + The following new flags are defined for the Attributes Flags TLV in + the LSP Attributes object. + + o Non-PHP behavior flag: + + 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: + + - Bit Number: 7 + + - Attribute flag carried in Path message: Yes + + - Attribute flag carried in Resv message: No + + - Attribute flag carried in RRO message: Yes + + + + + +Ali, et al. Standards Track [Page 7] + +RFC 6511 Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012 + + + o OOB mapping flag: + + 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: + + - Bit Number: 8 + + - Attribute flag carried in Path message: Yes + + - Attribute flag carried in Resv message: No + + - Attribute flag carried in RRO message: Yes + +4.2. New RSVP Error Sub-Code + + For Error Code = 25 "Notify Error" (see [RFC3209]), the following + sub-code is defined. + + Sub-code Value + -------- ----- + + No OOB mapping received 12 + +5. Acknowledgements + + The authors would like to thank Yakov Rekhter for his suggestions on + this document. + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. + Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 + Functional Specification", RFC 2205, September 1997. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, December 2001. + + + +Ali, et al. Standards Track [Page 8] + +RFC 6511 Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012 + + + [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Resource ReserVation Protocol- + Traffic Engineering (RSVP-TE) Extensions", RFC 3473, + January 2003. + + [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. + Yasukawa, Ed., "Extensions to Resource Reservation + Protocol - Traffic Engineering (RSVP-TE) for Point-to- + Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May + 2007. + + [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. + Ayyangarps, "Encoding of Attributes for MPLS LSP + Establishment Using Resource Reservation Protocol Traffic + Engineering (RSVP-TE)", RFC 5420, February 2009. + + [RFC6510] Berger, L. and G. Swallow, "Resource Reservation Protocol + (RSVP) Message Formats for Label Switched Path (LSP) + Attributes Objects", RFC 6510, February 2012. + +6.2. Informative References + + [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol + Label Switched (MPLS) Data Plane Failures", RFC 4379, + February 2006. + + [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private + LAN Service (VPLS) Using BGP for Auto-Discovery and + Signaling", RFC 4761, January 2007. + + [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, July 2010. + + [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, + L., and L. Berger, "A Framework for MPLS in Transport + Networks", RFC 5921, July 2010. + + [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. + + [RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in + MPLS/BGP IP VPNs", RFC 6513, February 2012. + + + + + + + +Ali, et al. Standards Track [Page 9] + +RFC 6511 Non-PHP and OOB Mapping for RSVP-TE LSPs February 2012 + + +Authors' Addresses + + Zafar Ali + Cisco Systems, Inc. + EMail: zali@cisco.com + + George Swallow + Cisco Systems, Inc. + EMail: swallow@cisco.com + + Rahul Aggarwal + Juniper Networks + EMail: raggarwa_1@yahoo.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ali, et al. Standards Track [Page 10] + |